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

[Markus Metz]

On Mon, Apr 7, 2014 at 12:19 AM, Helena Mitasova <hmitaso at ncsu.edu> wrote:
> 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").

Thinking about it, keeping devbr6 is fine with me, we just need to
maintain some discipline to apply the same changes to both devbr6 and
relbr6. Therefore, all developers should have write access to devbr6,
otherwise Hamish has to port all bug fixes made to relbr6 back to
devbr6. Since the code base of devbr6 and relbr6 is largely identical,
the same fix can be applied to both branches which is not a lot of
work. We might need to make another effort to synchronize the code
base of devbr6 and relbr6 to further facilitate backporting of bug
fixes.

>
> I think that if Hamish can maintain GRASS6 line this will free the time for all other developers to focus on GRASS7.

Sounds reasonable.

Markus M


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