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

[Helena Mitasova]

I believe that we have a communication problem here rather than a disagreement about the GRASS6.5:

Hamish says:
"GRASS 6.x is already far along into bugfix maintenance mode.
*Please, just leave it to naturally and quietly make its way into history.*
 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. "

which is pretty much in agreement with Martin's:
"I think we should really stop thinking about GRASS 6 "development",
So please bug fix only should go there (relbr64). No new functionality."

So I think that we have a broad agreement on maintenance only mode for grass6 line,
and if there is a concern that new features will be added to grass6.5, perhaps we can keep it
in read-only mode as suggested in one of the initial emails in this discussion and have
only Hamish keep write access for testing ("staging area").

I think that if Hamish can maintain GRASS6 line this will free the time for all other developers to focus on GRASS7.
Regarding GRASS7 - it is in a pretty good shape, we have been using it in classes since the fall semester
and I was quite surprised how little changes are needed to update the full semester course material for GRASS7.

Helena



Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmitaso at ncsu.edu

"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” 

On Apr 6, 2014, at 4:45 PM, Markus Metz wrote:

> 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-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev