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.gisw...@gmail.com> ha scritto: > On Sun, Apr 6, 2014 at 3:16 PM, Moritz Lennert > <mlenn...@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-...@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/grass-psc > _______________________________________________ > grass-psc mailing list > grass-...@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-psc >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev