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

[Massimiliano Cannata]

My 1 cent or less...

I think grass7 shold be the focus of the project now, the place where new
stuff should be developed, and that versions 6 are for bugfix only.
Why should I develop something new not in the latest software version?

All this thinking of a "good enough " version 7 (which I think already
exists, isn't?).

Maxi

Il 6-apr-2014 22:45 "Markus Metz" <markus.metz.giswork at gmail.com> ha
scritto:

> 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
> _______________________________________________
> grass-psc mailing list
> grass-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-psc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140406/664013e4/attachment.html>