[pgrouting-dev] Repository cleanup (branches)

Stephen Woodbridge woodbri at swoodbridge.com
Fri May 3 12:27:02 PDT 2013


On 5/3/2013 2:45 PM, Daniel Kastl wrote:
> Over the time several branches were created in the pgRouting repository.
> Some were for Google Summer of Code or development of new algorithms,
> others for packaging and some for working on the new 2.0 release.
>
> As Steve has completed a lot of tasks for a new release, I think it's
> time to do some repository cleanup: mainly get rid of useless branches
> and give them proper names.
>
> I have created a list of the current branches and added comments (2nd
> sheet):
> https://docs.google.com/a/georepublic.de/spreadsheet/ccc?key=0AiIg1pkkh_MRdGQzOEhyaXlndkN3eHdGNkpyQ0pMZFE#gid=4
>
> By deleting the Debian packaging related branches, nothing gets lost. It
> was an attempt to automate packaging, but this might be done better.
>
> The most important change would be to introduce a "pgr-1.x" and a
> "pgr-2.x" branch, which should be "safe" to use. Releases (alpha, beta,
> RC, stable) would be tagged within these branches.
> The "master" branch then would contain the current state of development.

Regarding the existing branches, I am all for cleaning and remove stuff 
that is dead, so I'm +1 on dropping the items you marked as <drop>.

I also removed the '?' regarding stuff the is 'not merged'. I think we 
need a review of the GSoC projects, darp, darp3, gsoc-multimodal, 
gsoc-tdsp, gsoc-two_q with regards to:

1. Are these documented/documentable to the point that people can 
generally use them?
2. Can we build tests for these?
3. Can we support them in the future?

In merging some of the other projects, I have found stuff that needs to 
be fixed and/or documented. This includes things like unused argments, 
passing a float cost column then converting it to an integer for 
computations, this is bad. I'll open tickets for these.

Thanks,
   -Steve



More information about the pgrouting-dev mailing list