<p dir="ltr">My 1 cent or less... </p>
<p dir="ltr">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.<br>
Why should I develop something new not in the latest software version?</p>
<p dir="ltr">All this thinking of a "good enough " version 7 (which I think already exists, isn't?). </p>
<p dir="ltr">Maxi<br><br></p>
<div class="gmail_quote">Il 6-apr-2014 22:45 "Markus Metz" <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> ha scritto:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, Apr 6, 2014 at 3:16 PM, Moritz Lennert<br>
<<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>
> On 06/04/14 13:46, Hamish wrote:<br>
><br>
><br>
>> As mentioned before, I wish to use the bulk of my grass dev time<br>
>> maintaining the grass 6 line. To do that properly I need a staging<br>
>> area, and devbr6 is it.<br>
<br>
I don't see the need for a devbr6 because maintaining the GRASS 6 line<br>
means backporting bug fixes from trunk. New functionality should be<br>
implemented in trunk, as in any other project. Bug fixes are then<br>
backported to the release branch, unfortunately we have now two<br>
release branches. Apart from addons, there will most probably not be<br>
any more GRASS 6 development, only GRASS 6 bug fixing, for which a<br>
GRASS 6 release branch is IMHO sufficient.<br>
<br>
I don't think it makes sense to maintain two GRASS major versions if<br>
development aka adding new functionality should take place in both.<br>
Some contributors like to implement new functionality in devbr6, but<br>
most contributors follow the (IMHO logical) way of trunk -> relbr. The<br>
now proposed development way of trunk -> relbr_7 -> devbr6 -> relbr6<br>
or or also devbr6 -> relbr6, skipping trunk, is unrealistic, will slow<br>
down GRASS development, and might lead to diverging branches.<br>
<br>
If GRASS 6, and release branch maintenance in general, is restricted<br>
to bug fixing, it should be easy to maintain trunk and two release<br>
branches. Granted that trunk is not abused as addon repository by<br>
adding untested code.<br>
<br>
My 2c,<br>
<br>
Markus M<br>
<br>
<br>
>> Hosting a clone on github for that is too<br>
>> ridiculous and broken a situation to begin to contemplate.<br>
>><br>
>> If devbr6 is removed I simply can not do the stable grass 6<br>
>> maintenance job properly. So without that there is really very little<br>
>> for me to contribute in future. It will not translate to me spending<br>
>> more time working on grass 7, only drive me away from the project.<br>
><br>
><br>
> I think that seen Hamish' continued effort for this project this a serious<br>
> enough situation to demand a solution.<br>
><br>
> But maybe the idea to actually release a first version of grass7 in a not to<br>
> far future is a way out.<br>
><br>
> Hamish, maybe you could be the official grass6 maintainer, managing the<br>
> whole grass6 development in the way you propose, i.e. any new development<br>
> and bugfixes first go into grass6dev for a period of testing, before _you_<br>
> make the decision that something can be backported to grass6release. I do<br>
> think however, that for this to work, we would need to regularly publish<br>
> snapshots of grass6dev for easy testing.<br>
><br>
> All other devs only commit to grass6dev, never to grass6release.<br>
><br>
> Just my 2¢,<br>
><br>
> Moritz<br>
><br>
> _______________________________________________<br>
> grass-psc mailing list<br>
> <a href="mailto:grass-psc@lists.osgeo.org">grass-psc@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/grass-psc" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-psc</a><br>
_______________________________________________<br>
grass-psc mailing list<br>
<a href="mailto:grass-psc@lists.osgeo.org">grass-psc@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-psc" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-psc</a><br>
</blockquote></div>