[pgrouting-dev] Repository cleanup (branches)

dkastl · May 3, 2013, 6:45pm

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.

To achieve this, I would propose to:

Branch “master” as “pgr-1.x”
Merge “sew-devel-2_0” branch into “master”
Then branch “master” as “pgr-2.x”

Does this make sense?

Daniel

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

Stephen_Woodbridge1 · May 3, 2013, 7:14pm

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.

To achieve this, I would propose to:

1. Branch "master" as "pgr-1.x"
2. Merge "sew-devel-2_0" branch into "master"
3. Then branch "master" as "pgr-2.x"

Does this make sense?

I can see saving the current master as pgr-1.x, this could be used to create point releases to fix bugs, or to make compatibility changes for postgres 2.x releases, etc.

My plan was to at some point make my branch the new master, that can happen as soon as the current master gets save in pgr-1.x

There is no need to create a pgr-2.x branch. The idea it to have the main development line in master and then to tag branches as significant points along that development. So the code stream SHOULD look like:

                           +--pgr-1.08-o +--pgr-1.09-o
            +- pgr-1.x----/---------------/------>
master----/---(merge sew-devl-2_0)---\---------->(pgr-3.0-dev)------>
                                       +--pgr-2.0-beta1-o-pgr-2.0-beta2-o

etc. the 'o' is were we cut a release.

So we only create a tag when we want to save the current state of things. We can create branches off the master for feature development and then they can be merged back into the master like I have done doe 2.0.

So I think we are saying the same thing.

-Steve

Stephen_Woodbridge1 · May 3, 2013, 7:27pm

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

dkastl · May 4, 2013, 1:46am

On Sat, May 4, 2013 at 4:14 AM, Stephen Woodbridge
<woodbri@swoodbridge.com>wrote:

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_**MRdGQzOEhyaXlndkN3eHdGNkpyQ0pM**ZFE#gid=4<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.

To achieve this, I would propose to:

1. Branch "master" as "pgr-1.x"
2. Merge "sew-devel-2_0" branch into "master"
3. Then branch "master" as "pgr-2.x"

Does this make sense?

I can see saving the current master as pgr-1.x, this could be used to
create point releases to fix bugs, or to make compatibility changes for
postgres 2.x releases, etc.

My plan was to at some point make my branch the new master, that can
happen as soon as the current master gets save in pgr-1.x

There is no need to create a pgr-2.x branch. The idea it to have the main
development line in master and then to tag branches as significant points
along that development. So the code stream SHOULD look like:

                          +--pgr-1.08-o +--pgr-1.09-o
           +- pgr-1.x----/---------------/--**---->
master----/---(merge sew-devl-2_0)---\---------->(**pgr-3.0-dev)------>
                                      +--pgr-2.0-beta1-o-pgr-2.0-**beta2-o

etc. the 'o' is were we cut a release.

So we only create a tag when we want to save the current state of things.
We can create branches off the master for feature development and then they
can be merged back into the master like I have done doe 2.0.

So I think we are saying the same thing.

Hi Steve,

I thought once more about it and what a new pgRouting user might expect,
who wants to compile pgRouting.
Also I remembered this quite popular Git branch model, which I found not
simple enough for small projects, but for some Open Source project it might
be suitable:
http://nvie.com/posts/a-successful-git-branching-model/

Following this branching model has the advantage, that many developers
should be familiar with it and that it should be "good enough".

Well, I think in Github world the "master" branch is something 99.9 percent
of all repositories have, and its's usually the branch displayed and
checked out by default.
So I would say, that as a user you expect that "master" isn't a (broken)
development branch

As the article mentions, there may be three types of branches:

   -
   - Feature branches
   - Release branches
   - Hotfix branches

I added a column to the branch list spreadsheet as this is a good
classification that also fits to some of the current branches. It actually
suits to all that are not marked as <drop>.
I think all these branches can be temporary, but there might be reasons to
keep them, ie.:

   - They haven't been merged yet (ie. darp branches)
   - Google Summer of Code branches to document a students work (ie. those
   starting with gsoc-)
   - They have been merged to the current version, but some people might
   want to make the changes also available for elder releases (ie. trsp)

If we follow the previously mentioned branching model, then we would create
a "develop" branch (maybe from "master"?) and merge "sew-devel-2_0" into it.
Since we might still support 1.x for some time though I would create an
extra branch for this.

I have modified the Spreadsheet accordingly.
Do you think this is better?

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

Stephen_Woodbridge1 · May 4, 2013, 2:03am

On 5/3/2013 9:46 PM, Daniel Kastl wrote:

On Sat, May 4, 2013 at 4:14 AM, Stephen Woodbridge
<woodbri@swoodbridge.com <mailto:woodbri@swoodbridge.com>> wrote:

    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___MRdGQzOEhyaXlndkN3eHdGNkpyQ0pM__ZFE#gid=4
        <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.

        To achieve this, I would propose to:

          1. Branch "master" as "pgr-1.x"
          2. Merge "sew-devel-2_0" branch into "master"
          3. Then branch "master" as "pgr-2.x"

        Does this make sense?

    I can see saving the current master as pgr-1.x, this could be used
    to create point releases to fix bugs, or to make compatibility
    changes for postgres 2.x releases, etc.

    My plan was to at some point make my branch the new master, that can
    happen as soon as the current master gets save in pgr-1.x

    There is no need to create a pgr-2.x branch. The idea it to have the
    main development line in master and then to tag branches as
    significant points along that development. So the code stream SHOULD
    look like:

                               +--pgr-1.08-o +--pgr-1.09-o
                +- pgr-1.x----/---------------/--__---->
    master----/---(merge sew-devl-2_0)---\---------->(__pgr-3.0-dev)------>

    +--pgr-2.0-beta1-o-pgr-2.0-__beta2-o

    etc. the 'o' is were we cut a release.

    So we only create a tag when we want to save the current state of
    things. We can create branches off the master for feature
    development and then they can be merged back into the master like I
    have done doe 2.0.

    So I think we are saying the same thing.

Hi Steve,

I thought once more about it and what a new pgRouting user might expect,
who wants to compile pgRouting.
Also I remembered this quite popular Git branch model, which I found not
simple enough for small projects, but for some Open Source project it
might be suitable:
http://nvie.com/posts/a-successful-git-branching-model/

Following this branching model has the advantage, that many developers
should be familiar with it and that it should be "good enough".

Well, I think in Github world the "master" branch is something 99.9
percent of all repositories have, and its's usually the branch displayed
and checked out by default.
So I would say, that as a user you expect that "master" isn't a (broken)
development branch

As the article mentions, there may be three types of branches:

  *
  * Feature branches
  * Release branches
  * Hotfix branches

I added a column to the branch list spreadsheet as this is a good
classification that also fits to some of the current branches. It
actually suits to all that are not marked as <drop>.
I think all these branches can be temporary, but there might be reasons
to keep them, ie.:

  * They haven't been merged yet (ie. darp branches)
  * Google Summer of Code branches to document a students work (ie.
    those starting with gsoc-)
  * They have been merged to the current version, but some people might
    want to make the changes also available for elder releases (ie. trsp)

If we follow the previously mentioned branching model, then we would
create a "develop" branch (maybe from "master"?) and merge
"sew-devel-2_0" into it.
Since we might still support 1.x for some time though I would create an
extra branch for this.

I have modified the Spreadsheet accordingly.
Do you think this is better?

Daniel,

I'm happy following the model on the link you referenced.
We should ask we can save a pdf ot that page in github and reference it in out development standards.

-Steve

dkastl · May 4, 2013, 2:30pm

I'm happy following the model on the link you referenced.
We should ask we can save a pdf ot that page in github and reference it in
out development standards.

I don't expect that this blog post will disappear, so instead of adding a
PDF to the repository, we could just add our (modified) model as a Wiki
page.
For now I added a paragraph to this Wiki page:
https://github.com/pgRouting/pgrouting/wiki/2.0-Development-Guidelines-and-Standards#git-branching-model
Could be extended later.

Daniel

PS: I removed "debian" related branches already

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de