Re: [GRASS-PSC] too many branches = retirement GRASS6.5.svn (=develbranch6)
Hi Markus, 2014-04-06 10:01 GMT+02:00 Markus Metz markus.metz.gisw...@gmail.com: big strong +1 for me, Martin +1 from me too, with one comment: I will only backport bugfixes to a releasebranch, not new functionality. That includes releasebranch_7_0. The (my) objective is to stabilize any releasebranch. this should become a rule, see Vaclav's suggestion about release policy. In this case we need to release GRASS at least once a year, otherwise users will be forced to wait for a new functionality too long time and part of them will switch to dev version. This is something what we should avoid in bigger scale. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches = retirement GRASS6.5.svn (=develbranch6)
Dear PSC members, 2014-04-06 10:08 GMT+02:00 Martin Landa landa.mar...@gmail.com: +1 from me too, with one comment: I will only backport bugfixes to a releasebranch, not new functionality. That includes releasebranch_7_0. The (my) objective is to stabilize any releasebranch. this should become a rule, see Vaclav's suggestion about release policy. In this case we need to release GRASS at least once a year, till now votes only 4 PSC members. For the record, here is related suggestion I mentioned above [1]. Martin [1] http://lists.osgeo.org/pipermail/grass-psc/2014-March/001150.html -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches = retirement GRASS6.5.svn (=develbranch6)
On Mon, Mar 31, 2014 at 10:04 AM, Martin Landa landa.mar...@gmail.com wrote: Hi all, 2014-03-31 9:57 GMT+02:00 Sören Gebbert soerengebb...@googlemail.com: +1 I agree to 100% big strong +1 for me, Martin also from me: retire GRASS6.5.svn (=develbranch6). markusN ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches = retirement GRASS6.5.svn (=develbranch6)
On 06/04/14 13:46, Hamish wrote: First of all, I believe this discussion belongs on the grass-dev list, not PSC. See RFC1. CC'in to dev-list releasebranch70 should not have been branched until 7.0RC1. Until RC1 it is just wasted effort to keep the two of them as a 1:1 mirror, so what's the point? If anyone wants to talk about unnecessary developer burden, start there. As already mentioned I was also a bit surprised by this. I'm not sure we are really ready for something more than a tech-preview (and not a real release), but maybe it could be the kick in the behind that we need to once and for all move over to GRASS7 as the main official branch... I also think that voting on Martin's proposal as such is a bit premature. I think we should discuss the pros and cons of different approaches a bit more before calling a vote. I think that experience has shown that the lack of clear policy on release management has caused frustration among developers. Personally, I'm somewhere between the two approaches. On the one hand what I understand to be Hamish' wish of having a debian-like system of unstable for ongoing cutting-edge development, testing as a staging area for more stabilized code and stable as rock-solid, albeit a bit outdated, On the other hand, I just haven't seen this work in GRASS up to now and I see a lot of frustration from those who find this system too heavy to carry. I don't know if that is because the procedure never was clear or whether we lack the equivalent of the debian ftp-managers to oversee the process, whether we just lack the discipline (which could be linked to the previous point) or whether the GRASS development team is just too small for such a process. One of the big differences, IMHO, is that a user of debian testing just has to apt-get update apt-get upgrade to get the lasted developments, whereas users of grass6dev has to compile it themselves (at least on GNU/Linux) as no distribution offers packages for that. This means that using testing is a much more involved process. So, before we start voting of release procedures, maybe we have to first clarify and agree upon our goals. I.e. decide on the ends before we decide on the means. Here is my attempt on some of the goals: - provide a rock-solid, just works, version of GRASS - provide easy access for users to new developments in GRASS - keep the burden on the dev-team as low as possible - make the whole development and release process very clear and explicit with defined procedures and (at least relative) timetables - enforce a certain level of discipline in the respect of these rules and procedures 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. 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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches = retirement GRASS6.5.svn (=develbranch6)
Hi, 2014-04-06 15:16 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be: As already mentioned I was also a bit surprised by this. I'm not sure we are really ready for something more than a tech-preview (and not a real release), but maybe it could be the kick in the behind that we need to once and for all move over to GRASS7 as the main official branch... well, what is missing from your point of view? I would be able to imagine to release 7.0.0 around June... Martin ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches = retirement GRASS6.5.svn (=develbranch6)
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-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches
On 29/03/14 07:04, Luca Delucchi wrote: Hi PSC, with the upcoming GRASS 7 release we have to many branches to maintain (releasebranch6, devbranch6, releasebranch7 and trunk). Can I ask you to take a decision about the future of all this branches? I could suggest something like: - keep releasebranch6 only for important bugfixes, no new feature and starting to forget it - put in reading mode or remove (after backport the differences with grass64) devbranch6 - releasebranch7 is the new stable release branch, so new features only when we are far from release a new version - trunk for new feature what do you think? The initial idea was to create a tech-preview release of grass7, not an official 7.0 release. Has that changed during the sprint ? If we only do a tech release, I don't think we really need a releasebranch. Just a short (max 2 weeks) commit freeze to trunk to make sure everything compiles and runs as expected (with known bugs) and then release. Concerning grass6, I agree that we should probably merge release and dev. Maybe - backport anything from dev to release that is stable enough for release (if there is anything left to backport) - publish grass6.4.4 - if there is anything in 6-dev which is not in trunk, then forward-port that if necessary/feasible - then, as you propose, abandon 6-dev and keep 6-release in maintenance mode Moritz ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches
Dear PSC, 2014-03-31 4:30 GMT+02:00 Yann Chemin yche...@gmail.com: +1 to remove devbranch6 after appropriate transfer of the needed to releasebranch6. same here +1, maybe not to remove, just to set as read only Do we have a tentative time line to freeze Grass6 release branch (1 year?) You mean GRASS 7 I guess, I personally think that we could freeze the release branch in July and probably release GRASS 7 in September or so... It is just my personal opinion. Martin ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches
On Mon, Mar 31, 2014 at 4:30 AM, Yann Chemin yche...@gmail.com wrote: In favour of giving the devbranch6 a prune, I cannot remember when I used grass6-dev last time... Obviously will maintain GRASS 6.4.x for more time, that's our LTS... +1 to remove devbranch6 after appropriate transfer of the needed to releasebranch6. I would speak about putting devbranch6 into read-only mode soon. There are still many changes not yet being backported to releasebranch64... a situation which I rather dislike. So devbranch6 should not be pruned but set to readonly. Markus ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches
On Mon, Mar 31, 2014 at 10:24 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: The initial idea was to create a tech-preview release of grass7, not an official 7.0 release. Has that changed during the sprint ? No, this is what happened: beta1 (called like this to maintain consistency with previous pre-releases). See also (pls improve that page!): http://trac.osgeo.org/grass/wiki/Release/7.0.0beta-News If we only do a tech release, I don't think we really need a releasebranch. Just a short (max 2 weeks) commit freeze to trunk to make sure everything compiles and runs as expected (with known bugs) and then release. This is likely causing more work than it helps. but we can see how it evolves. Concerning grass6, I agree that we should probably merge release and dev. Maybe - backport anything from dev to release that is stable enough for release (if there is anything left to backport) There is a LOT left since some people only feed devbr6 and then don't backport to relbr6... I got a bit tired of comparing it (did so many times in the past). - publish grass6.4.4 Yes. Since we also fixed the r.li suite, it looks pretty good. - if there is anything in 6-dev which is not in trunk, then forward-port that if necessary/feasible Perhaps there is, not idea (see comment above). - then, as you propose, abandon 6-dev and keep 6-release in maintenance mode Yes. Markus ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches
On 31/03/14 10:34, Markus Neteler wrote: On Mon, Mar 31, 2014 at 10:24 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: The initial idea was to create a tech-preview release of grass7, not an official 7.0 release. Has that changed during the sprint ? No, this is what happened: beta1 (called like this to maintain consistency with previous pre-releases). I did see that, but for me a beta release is a first version of what will be a final grass7.0 release. A tech-preview, in my understanding, is more of a snapshot of an ongoing development branch. But if the general feeling is that we can actually release a grass7.0 by the summer or early autumn, then let's do it. See also (pls improve that page!): http://trac.osgeo.org/grass/wiki/Release/7.0.0beta-News If we only do a tech release, I don't think we really need a releasebranch. Just a short (max 2 weeks) commit freeze to trunk to make sure everything compiles and runs as expected (with known bugs) and then release. This is likely causing more work than it helps. but we can see how it evolves. I think it creates more work during the short freeze, but avoids the need of multiplying branches. If the procedure is clear and the calendar is agreed upon and all devs collaborate then it shouldn't be too much trouble. Moritz ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches
Along the same lines, I don’t feel in the loop enough to judge specifics, but like the thrust of the discussion. So +0 from me too, if it’s needed. On Mar 30, 2014, at 17:32 , Massimiliano Cannata massimiliano.cann...@supsi.ch wrote: I'm in general in favor, but would like to know the opinion of the guru (Markus) for that. You guys seems to have clear and already agreed opinion on that.. ;-) Don't know if vote is needed, but for me is +0 Maxi On Sat, Mar 29, 2014 at 7:04 AM, Luca Delucchi lucadel...@gmail.com wrote: Hi PSC, with the upcoming GRASS 7 release we have to many branches to maintain (releasebranch6, devbranch6, releasebranch7 and trunk). Can I ask you to take a decision about the future of all this branches? I could suggest something like: - keep releasebranch6 only for important bugfixes, no new feature and starting to forget it - put in reading mode or remove (after backport the differences with grass64) devbranch6 - releasebranch7 is the new stable release branch, so new features only when we are far from release a new version - trunk for new feature what do you think? Thanks a lot Best regards -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc -- Massimiliano Cannata Professore SUPSI in ingegneria Geomatica Responsabile settore Geomatica Istituto scienze della Terra Dipartimento ambiente costruzione e design Scuola universitaria professionale della Svizzera italiana Campus Trevano, CH - 6952 Canobbio Tel. +41 (0)58 666 62 14 Fax +41 (0)58 666 62 09 massimiliano.cann...@supsi.ch www.supsi.ch/ist ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches
In favour of giving the devbranch6 a prune, I cannot remember when I used grass6-dev last time... +1 to remove devbranch6 after appropriate transfer of the needed to releasebranch6. Do we have a tentative time line to freeze Grass6 release branch (1 year?) Yann On 29 March 2014 11:34, Luca Delucchi lucadel...@gmail.com wrote: Hi PSC, with the upcoming GRASS 7 release we have to many branches to maintain (releasebranch6, devbranch6, releasebranch7 and trunk). Can I ask you to take a decision about the future of all this branches? I could suggest something like: - keep releasebranch6 only for important bugfixes, no new feature and starting to forget it - put in reading mode or remove (after backport the differences with grass64) devbranch6 - releasebranch7 is the new stable release branch, so new features only when we are far from release a new version - trunk for new feature what do you think? Thanks a lot Best regards -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc -- ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches = retirement GRASS6.5.svn (=develbranch6)
+1 On 30 March 2014 02:47, Helmut Kudrnovsky hel...@web.de wrote: Dear GRASS GIS PSC, margherita wrote Dear Luca, thank you for raising this issue, On Sat, Mar 29, 2014 at 7:04 AM, Luca Delucchi lt; lucadeluge@ gt; wrote: with the upcoming GRASS 7 release we have to many branches to maintain (releasebranch6, devbranch6, releasebranch7 and trunk). Can I ask you to take a decision about the future of all this branches? I could suggest something like: - keep releasebranch6 only for important bugfixes, no new feature and starting to forget it - put in reading mode or remove (after backport the differences with grass64) devbranch6 - releasebranch7 is the new stable release branch, so new features only when we are far from release a new version - trunk for new feature what do you think? I'm in favor. Having too many branches from users point of view only raises confusion, and for developers is much more effort required to keep track of everything. My 2c Regards, Madi Thanks a lot Best regards -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-psc mailing list grass-psc@.osgeo http://lists.osgeo.org/mailman/listinfo/grass-psc -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-leo@.europa Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-psc mailing list grass-psc@.osgeo http://lists.osgeo.org/mailman/listinfo/grass-psc it was a pleasure to meet GRASS devs but also GRASS users at the Vienna OSGeo Code Sprint [1] which was also a GRASS community sprint [2]. In addition it was a honour for me to help getting beta release of GRASS GIS 7.0.0, the upcoming stable release, into the wild. Now for us, GRASS devs _and_ users, there are now several branches of GRASS GIS (trunk, releasebranch7, releasebranch6, develbranch6) [4] to maintain, test and use. A lot of important improvements and new, exciting and fancy features are now in trunk and releasebranch7 which will never be backported to releasebranch6 and so on. It is time for GRASS devs _and_ users to focus development on and maintain, improve, test and use GRASS7. As I trust in GRASS devs experience and carefulness of code submitting and in order (1) to _minimize_ GRASS user's confusion which version to test, to use and to give feedback for improvements and bug fixing and (2) to _reduce_ GRASS dev's burden to maintain, develop, improve and to fix bugs in trunk and 3 branches I request the retirement of GRASS6.5.svn (=develbranch6) and keep releasebranch6 for release only in bug fixing mode and trunk and releasebranch7 for future improvements and development. best regards Helmut GRASS user, sometimes lightweight GRASS dev, osgeo charter member [1] http://wiki.osgeo.org/wiki/Vienna_Code_Sprint_2014 [2] http://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Vienna_2014 [3] http://grasswiki.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Vienna_2014 [4] http://trac.osgeo.org/grass/browser/grass - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/too-many-branches-tp5131993p5132059.html Sent from the GRASS-PSC mailing list archive at Nabble.com. ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc -- ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
[GRASS-PSC] too many branches
Hi PSC, with the upcoming GRASS 7 release we have to many branches to maintain (releasebranch6, devbranch6, releasebranch7 and trunk). Can I ask you to take a decision about the future of all this branches? I could suggest something like: - keep releasebranch6 only for important bugfixes, no new feature and starting to forget it - put in reading mode or remove (after backport the differences with grass64) devbranch6 - releasebranch7 is the new stable release branch, so new features only when we are far from release a new version - trunk for new feature what do you think? Thanks a lot Best regards -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches
Dear Luca, thank you for raising this issue, On Sat, Mar 29, 2014 at 7:04 AM, Luca Delucchi lucadel...@gmail.com wrote: with the upcoming GRASS 7 release we have to many branches to maintain (releasebranch6, devbranch6, releasebranch7 and trunk). Can I ask you to take a decision about the future of all this branches? I could suggest something like: - keep releasebranch6 only for important bugfixes, no new feature and starting to forget it - put in reading mode or remove (after backport the differences with grass64) devbranch6 - releasebranch7 is the new stable release branch, so new features only when we are far from release a new version - trunk for new feature what do you think? I'm in favor. Having too many branches from users point of view only raises confusion, and for developers is much more effort required to keep track of everything. My 2c Regards, Madi Thanks a lot Best regards -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] too many branches = retirement GRASS6.5.svn (=develbranch6)
Dear GRASS GIS PSC, margherita wrote Dear Luca, thank you for raising this issue, On Sat, Mar 29, 2014 at 7:04 AM, Luca Delucchi lt; lucadeluge@ gt; wrote: with the upcoming GRASS 7 release we have to many branches to maintain (releasebranch6, devbranch6, releasebranch7 and trunk). Can I ask you to take a decision about the future of all this branches? I could suggest something like: - keep releasebranch6 only for important bugfixes, no new feature and starting to forget it - put in reading mode or remove (after backport the differences with grass64) devbranch6 - releasebranch7 is the new stable release branch, so new features only when we are far from release a new version - trunk for new feature what do you think? I'm in favor. Having too many branches from users point of view only raises confusion, and for developers is much more effort required to keep track of everything. My 2c Regards, Madi Thanks a lot Best regards -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-psc mailing list grass-psc@.osgeo http://lists.osgeo.org/mailman/listinfo/grass-psc -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-leo@.europa Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-psc mailing list grass-psc@.osgeo http://lists.osgeo.org/mailman/listinfo/grass-psc it was a pleasure to meet GRASS devs but also GRASS users at the Vienna OSGeo Code Sprint [1] which was also a GRASS community sprint [2]. In addition it was a honour for me to help getting beta release of GRASS GIS 7.0.0, the upcoming stable release, into the wild. Now for us, GRASS devs _and_ users, there are now several branches of GRASS GIS (trunk, releasebranch7, releasebranch6, develbranch6) [4] to maintain, test and use. A lot of important improvements and new, exciting and fancy features are now in trunk and releasebranch7 which will never be backported to releasebranch6 and so on. It is time for GRASS devs _and_ users to focus development on and maintain, improve, test and use GRASS7. As I trust in GRASS devs experience and carefulness of code submitting and in order (1) to _minimize_ GRASS user's confusion which version to test, to use and to give feedback for improvements and bug fixing and (2) to _reduce_ GRASS dev's burden to maintain, develop, improve and to fix bugs in trunk and 3 branches I request the retirement of GRASS6.5.svn (=develbranch6) and keep releasebranch6 for release only in bug fixing mode and trunk and releasebranch7 for future improvements and development. best regards Helmut GRASS user, sometimes lightweight GRASS dev, osgeo charter member [1] http://wiki.osgeo.org/wiki/Vienna_Code_Sprint_2014 [2] http://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Vienna_2014 [3] http://grasswiki.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Vienna_2014 [4] http://trac.osgeo.org/grass/browser/grass - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/too-many-branches-tp5131993p5132059.html Sent from the GRASS-PSC mailing list archive at Nabble.com. ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
