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
[GRASS-PSC] RFC3: New voting rules
PSC; since the voting discussion is scattered around in various email threads, I start a new one to separate it from ongoing motions. Please re-express your comments as answer to this email. RFC3: PSC Voting Procedures http://grass.osgeo.org/programming7/rfc3_psc.html Issues: - people are travelling and periodically offline - not all members may need to vote (majority, quorum, etc) - keep it simple - ... Best, Markus ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] RFC3: New voting rules
Hi, On Sun, Apr 6, 2014 at 12:48 PM, Markus Neteler nete...@osgeo.org wrote: PSC; since the voting discussion is scattered around in various email threads, I start a new one to separate it from ongoing motions. Please re-express your comments as answer to this email. RFC3: PSC Voting Procedures http://grass.osgeo.org/programming7/rfc3_psc.html I fully support this proposal. My only concern raises about business day definition. PSC members are from all over the world and it might happen to be public holidays in some countries and working days in some else. I'd propose to change this sentence: Proposals are available for review for at least four business days into: Proposals are available for review for at least seven days Would this be OK? Thanks, Madi -- 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)
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] RFC3: New voting rules
Madi’s suggestion makes sense to me. I suppose that the wording of #2 could be modified to allow for the case where all members have already voted with no dissenting comments, if we think a rush situation might come up. I.e. instead of just increasing 4 days to 7 days, it could be worded as a default 7 days if comments are still being exchanged and votes coming in, but less time if everyone has voted without issue. On Apr 6, 2014, at 07:48 , Margherita Di Leo direg...@gmail.com wrote: Hi, On Sun, Apr 6, 2014 at 12:48 PM, Markus Neteler nete...@osgeo.org wrote: PSC; since the voting discussion is scattered around in various email threads, I start a new one to separate it from ongoing motions. Please re-express your comments as answer to this email. RFC3: PSC Voting Procedures http://grass.osgeo.org/programming7/rfc3_psc.html I fully support this proposal. My only concern raises about business day definition. PSC members are from all over the world and it might happen to be public holidays in some countries and working days in some else. I'd propose to change this sentence: Proposals are available for review for at least four business days into: Proposals are available for review for at least seven days Would this be OK? Thanks, Madi -- 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 ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] RFC3: New voting rules
On 06/04/14 12:48, Markus Neteler wrote: PSC; since the voting discussion is scattered around in various email threads, I start a new one to separate it from ongoing motions. Please re-express your comments as answer to this email. RFC3: PSC Voting Procedures http://grass.osgeo.org/programming7/rfc3_psc.html Thank you for this revised version ! I agree with Madi on the way the delay is expressed. I have two major remarks, though: - We should define more clearly what should be subject to voting. At this stage we only have this in the PSC guidelines: The following issue(s) must have a vote called before a decision is reached: Granting source code repository write access for new developers Selection of a committee Chair Maybe we need to amend this a bit in the light of the current votes being put onto this list ? - Proposals are written up and submitted on the mailing list for discussion. Any committee member may call a vote on any proposal, although it is normal practice for the proposer to call the vote. I would propose that in order to avoid vote inflation, any proposal should be submitted by at least three members of the PSC, not just one. This should ensure a bit of discussion and peer review before submission, thus avoiding long debates on proposals that just are not ripe for vote, yet. 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] RFC3: New voting rules
On Sun, Apr 6, 2014 at 3:22 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 06/04/14 12:48, Markus Neteler wrote: PSC; since the voting discussion is scattered around in various email threads, I start a new one to separate it from ongoing motions. Please re-express your comments as answer to this email. RFC3: PSC Voting Procedures http://grass.osgeo.org/programming7/rfc3_psc.html Thank you for this revised version ! just FYI: it is not revised but as before (several years, I guess). Markus ___ 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] RFC3: New voting rules
In my opinion things worked quite fine in the last years. - Madi proposal is also fine: 7 days may give more chance for everybody to be connected for voting. - Probably having majority only after that period would suffice for motion to pass. - Vote is mandatory for write access to SVN, otherwise take place only if called (important issues only in my opinion or when discussion in mailing list do not bring to a commonly accepted solution). This is just my point of view. :-) Maxi Il 6-apr-2014 19:24 Markus Neteler nete...@osgeo.org ha scritto: On Sun, Apr 6, 2014 at 3:22 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 06/04/14 12:48, Markus Neteler wrote: PSC; since the voting discussion is scattered around in various email threads, I start a new one to separate it from ongoing motions. Please re-express your comments as answer to this email. RFC3: PSC Voting Procedures http://grass.osgeo.org/programming7/rfc3_psc.html Thank you for this revised version ! just FYI: it is not revised but as before (several years, I guess). Markus ___ 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] [GRASS-dev] too many branches = retirement GRASS6.5.svn (=develbranch6)
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). I think that if Hamish can maintain GRASS6 line this will free the time for all other developers to focus on GRASS7. 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 hmit...@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 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-dev mailing list grass-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-psc mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
Re: [GRASS-PSC] RFC3: New voting rules
I second Helena on quorum (min 51%), and also +1 for the 7 days suggestion of MaDi. On 7 April 2014 06:19, Helena Mitasova hmit...@ncsu.edu wrote: I agree with the voting rules with the following changes/comments: - change 4 business days to seven days to avoid confusion given that business days may be different in different countries due to holidays (as already suggested) - I am confused about #6 - does this mean that it is enough for 2 PSC members (out of 10?) to agree to accept a proposal? Should we have at least a simple majority? Does this voting procedure apply to svn access as well? 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 hmit...@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 6:48 AM, Markus Neteler wrote: PSC; since the voting discussion is scattered around in various email threads, I start a new one to separate it from ongoing motions. Please re-express your comments as answer to this email. RFC3: PSC Voting Procedures http://grass.osgeo.org/programming7/rfc3_psc.html Issues: - people are travelling and periodically offline - not all members may need to vote (majority, quorum, etc) - keep it simple - ... Best, Markus ___ 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 mailing list grass-psc@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc
