While I agree with this overall, I don’t see why we need 2 GRASS branches. What is the value in 2 GRASS 6 branches that cannot be achieved with 1 branch?
Michael ______________________________ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Apr 7, 2014, at 12:07 PM, Markus Metz <[email protected]> wrote: > On Mon, Apr 7, 2014 at 12:19 AM, Helena Mitasova <[email protected]> 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 >> [email protected] >> >> "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 >>> <[email protected]> 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 >>>> [email protected] >>>> http://lists.osgeo.org/mailman/listinfo/grass-psc >>> _______________________________________________ >>> grass-dev mailing list >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/grass-dev >> >> _______________________________________________ >> grass-psc mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/grass-psc > _______________________________________________ > grass-psc mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-psc _______________________________________________ grass-psc mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-psc
