[GRASS-dev] [GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

Markus Metz markus.metz.giswork at gmail.com
Sun Apr 6 13:45:51 PDT 2014


On Sun, Apr 6, 2014 at 3:16 PM, Moritz Lennert
<mlennert at club.worldonline.be> wrote:
> On 06/04/14 13:46, Hamish wrote:
>
>
>> As mentioned before, I wish to use the bulk of my grass dev time
>> maintaining the grass 6 line. To do that properly I need a staging
>> area, and devbr6 is it.

I don't see the need for a devbr6 because maintaining the GRASS 6 line
means backporting bug fixes from trunk. New functionality should be
implemented in trunk, as in any other project. Bug fixes are then
backported to the release branch, unfortunately we have now two
release branches. Apart from addons, there will most probably not be
any more GRASS 6 development, only GRASS 6 bug fixing, for which a
GRASS 6 release branch is IMHO sufficient.

I don't think it makes sense to maintain two GRASS major versions if
development aka adding new functionality should take place in both.
Some contributors like to implement new functionality in devbr6, but
most contributors follow the (IMHO logical) way of trunk -> relbr. The
now proposed development way of trunk -> relbr_7 -> devbr6 -> relbr6
or or also devbr6 -> relbr6, skipping trunk, is unrealistic, will slow
down GRASS development, and might lead to diverging branches.

If GRASS 6, and release branch maintenance in general, is restricted
to bug fixing, it should be easy to maintain trunk and two release
branches. Granted that trunk is not abused as addon repository by
adding untested code.

My 2c,

Markus M


>> Hosting a clone on github for that is too
>> ridiculous and broken a situation to begin to contemplate.
>>
>> If devbr6 is removed I simply can not do the stable grass 6
>> maintenance job properly. So without that there is really very little
>> for me to contribute in future. It will not translate to me spending
>> more time working on grass 7, only drive me away from the project.
>
>
> I think that seen Hamish' continued effort for this project this a serious
> enough situation to demand a solution.
>
> But maybe the idea to actually release a first version of grass7 in a not to
> far future is a way out.
>
> Hamish, maybe you could be the official grass6 maintainer, managing the
> whole grass6 development in the way you propose, i.e. any new development
> and bugfixes first go into grass6dev for a period of testing, before _you_
> make the decision that something can be backported to grass6release. I do
> think however, that for this to work, we would need to regularly publish
> snapshots of grass6dev for easy testing.
>
> All other devs only commit to grass6dev, never to grass6release.
>
> Just my 2¢,
>
> Moritz
>
> _______________________________________________
> grass-psc mailing list
> grass-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-psc


More information about the grass-dev mailing list