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 = 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
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