Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
On Tue, Nov 29, 2011 at 10:00 PM, Neha Narkhede neha.narkh...@gmail.com wrote: Hi, The context for this is the discussion here - http://markmail.org/message/rsxjgrrufc6khlqy?q=overhead+list:org.apache.incubator.general This was a long discussion with no clear answers. We would like to know if it is OK to either - 1. shorten the release VOTE for change to one non-code file The voting policy only says: Votes should generally be permitted to run for at least 72 hours to provide an opportunity for all concerned persons to participate regardless of their geographic locations. - http://www.apache.org/foundation/voting.html So nothing there says 72 hours is an absolute minimum. I've seen TLPs do releases in less than 72 hours, usually to fix something like a very serious issue in a previous release. And this was discussed on this list a year or so ago and consensus was that that was ok. That should be fine for poddlings too but I'd expect you'd need a very good reason to convince three Incubator PMC members to vote for a release like that. 2. run 72 hour vote in parallel on the dev list as well as on general@ Thats totally fine and happens often, as Paul pointed out Libcloud did that for most of its releases and many other poddlings have too. If a poddling keeps sending low quality releases to votes on general@ people might stop bothering to review and vote on them so poddlings probably only want to do this once they're a bit confident with their releases. What we would like to know is if any member would -1 the vote if we choose to do either of the above ? Even if they did a -1 on a release vote is not a veto. Thanks, Neha - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
Yupyup. I thought I'd add a little background rant here, that I wrote for the jena podling a bit ago. Purely optional reading but maybe illuminating for some. cheerio, - Leo On Tue, Nov 8, 2011 at 9:44 PM, Leo Simons m...@leosimons.com wrote: On Fri, Nov 4, 2011 at 3:54 PM, Benson Margulies bimargul...@gmail.com wrote: snip/ Release votes are about universally 72 hours. Benson is of course right, but I like pointing out reasons behind such conventions, so I'm going to give you a belated, long answer anyway, reading it is optional :-) I'm always a little annoyed when I see people say something like sorry your vote doesn't count it was too late, or you can't do that yet you have to wait 3 more hours someone might still vote -1 :-) The underlying point is to make sure to give everyone a reasonable chance to make up their minds and then vote (in the broadest everyone sense, and even if they may not have a binding vote). Religiously sticking to numbers is silly. Use your judgement. The duty of PMC members in the end is to act in the best interests of the apache foundation (which acts in the best interest of the general public), not to follow (or force onto others) particular rules. Some examples to illustrate, probably unneeded, but... If you consider people might be a day behind on their e-mail, and they might be on the other side of the globe, that's 36 hours absolute worst-case. If you add a weekend in the middle from friday 5pm to monday 9pm that's a total of 36 + 7 + 9 + 48 = 100 hours. If you consider that it may take a day, say, to verify a release and regression test it (say across your, err, 1000 node hadoop cluster, whatever), that's 124 hours. So you could have a long argument that 72 hours is not enough, and decide as a project you will use a 124 hour minimum. You're allowed to do that, if that's what you think is best for your community. On the one extreme you can imagine a project with all the people on the mailing list being on UTC time or close to it where a vote is almost pro forma since consensus was clear anyway, where you start the vote at 9am in the morning and everyone subscribed to the mailing list has voted by 11am. Do you then want to wait 122 additional hours because that's a rule? Not really. On the other extreme, for something like here's a proposal to bring geronimo / harmony / openoffice into apache that impacts loads and loads of people and might cause corporations to move mountains, it's considered normal to allow reasonable amounts of time for discussion, where reasonable could be over a month. 72 hours turns out from experience to be a nice standard number for release votes and other such important milestones, because it gives a very reasonable amount of time allowing for the broadest possible participation, without becoming a super-annoying super-long wait. It avoids people holding a project hostage and stalling, yet also avoids the temptation to rush through contentious changes when the majority (but not all) people are co-located at a hackathon, etc. But, use your own judgement. If one of the companies one of you works at would really really like an extra day to regression test a new version of jena at a large customer deployment, and that is delayed a bit because someone tied up all the jenkins instances with their hadoop stuff, it'll probably be a good idea to wait for the results rather than push through with a vote, since that means the general public gets to benefit from a better-tested release. This kind of balancing thing is, incidentally, why the how to do apache stuff docs don't have that many hard rules. Stubborn people like me keep editing them out :) cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
On 30 November 2011 14:11, Leo Simons m...@leosimons.com wrote: Yupyup. I thought I'd add a little background rant here, that I wrote for the jena podling a bit ago. Purely optional reading but maybe illuminating for some. cheerio, - Leo On Tue, Nov 8, 2011 at 9:44 PM, Leo Simons m...@leosimons.com wrote: On Fri, Nov 4, 2011 at 3:54 PM, Benson Margulies bimargul...@gmail.com wrote: snip/ Release votes are about universally 72 hours. Benson is of course right, but I like pointing out reasons behind such conventions, so I'm going to give you a belated, long answer anyway, reading it is optional :-) I'm always a little annoyed when I see people say something like sorry your vote doesn't count it was too late, or you can't do that yet you have to wait 3 more hours someone might still vote -1 :-) The underlying point is to make sure to give everyone a reasonable chance to make up their minds and then vote (in the broadest everyone sense, and even if they may not have a binding vote). Religiously sticking to numbers is silly. Use your judgement. The duty of PMC members in the end is to act in the best interests of the apache foundation (which acts in the best interest of the general public), not to follow (or force onto others) particular rules. Some examples to illustrate, probably unneeded, but... If you consider people might be a day behind on their e-mail, and they might be on the other side of the globe, that's 36 hours absolute worst-case. If you add a weekend in the middle from friday 5pm to monday 9pm that's a total of 36 + 7 + 9 + 48 = 100 hours. If you consider that it may take a day, say, to verify a release and regression test it (say across your, err, 1000 node hadoop cluster, whatever), that's 124 hours. So you could have a long argument that 72 hours is not enough, and decide as a project you will use a 124 hour minimum. You're allowed to do that, if that's what you think is best for your community. On the one extreme you can imagine a project with all the people on the mailing list being on UTC time or close to it where a vote is almost pro forma since consensus was clear anyway, where you start the vote at 9am in the morning and everyone subscribed to the mailing list has voted by 11am. Do you then want to wait 122 additional hours because that's a rule? Not really. On the other extreme, for something like here's a proposal to bring geronimo / harmony / openoffice into apache that impacts loads and loads of people and might cause corporations to move mountains, it's considered normal to allow reasonable amounts of time for discussion, where reasonable could be over a month. 72 hours turns out from experience to be a nice standard number for release votes and other such important milestones, because it gives a very reasonable amount of time allowing for the broadest possible participation, without becoming a super-annoying super-long wait. It avoids people holding a project hostage and stalling, yet also avoids the temptation to rush through contentious changes when the majority (but not all) people are co-located at a hackathon, etc. But, use your own judgement. If one of the companies one of you works at would really really like an extra day to regression test a new version of jena at a large customer deployment, and that is delayed a bit because someone tied up all the jenkins instances with their hadoop stuff, it'll probably be a good idea to wait for the results rather than push through with a vote, since that means the general public gets to benefit from a better-tested release. This kind of balancing thing is, incidentally, why the how to do apache stuff docs don't have that many hard rules. Stubborn people like me keep editing them out :) Which is fine if the reason why the rule is soft is made explicit. Otherwise one cannot tell if the document is complete. I keep saying this: IMO documenting the reasons behind the rules is vital to understand them. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
On Tue, Nov 29, 2011 at 2:00 PM, Neha Narkhede neha.narkh...@gmail.com wrote: Hi, The context for this is the discussion here - http://markmail.org/message/rsxjgrrufc6khlqy?q=overhead+list:org.apache.incubator.general This was a long discussion with no clear answers. We would like to know if it is OK to either - 1. shorten the release VOTE for change to one non-code file 2. run 72 hour vote in parallel on the dev list as well as on general@ What we would like to know is if any member would -1 the vote if we choose to do either of the above ? You can most definitely run the votes in parallel. I did this for almost all of the Libcloud releases while it was in incubator. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
On 11/29/2011 4:00 PM, Neha Narkhede wrote: We would like to know if it is OK to either - 1. shorten the release VOTE for change to one non-code file 2. run 72 hour vote in parallel on the dev list as well as on general@ I've never seen a point to 2) to running serial votes. You need only 3 +1's (more +1's than -1's)... usually three mentors are enough to finish amoung the dev@ list, but announcing the vote (and its conclusion) on the general@ list seems entirely appropriate. If folks at general@ would like to have more input on the release, the ppmc dev@ list is really the best place to get involved. It is important to always allow 72 full hours. The reason is simple, we have participants in nearly every timezone, people who are here only on their own time, and more people who are here almost exclusively on work hours. 72 hours is long enough to accommodate them all, if they care to participate. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
On 11/29/2011 7:27 PM, William A. Rowe Jr. wrote: On 11/29/2011 4:00 PM, Neha Narkhede wrote: We would like to know if it is OK to either - 1. shorten the release VOTE for change to one non-code file 2. run 72 hour vote in parallel on the dev list as well as on general@ I've never seen a point to 2) to running serial votes. You need only 3 +1's (more +1's than -1's)... usually three mentors are enough to finish amoung the dev@ list, but announcing the vote (and its conclusion) on the general@ list seems entirely appropriate. If folks at general@ would like to have more input on the release, the ppmc dev@ list is really the best place to get involved. It is important to always allow 72 full hours. The reason is simple, we have participants in nearly every timezone, people who are here only on their own time, and more people who are here almost exclusively on work hours. 72 hours is long enough to accommodate them all, if they care to participate. [... trackpad arguing with me over whether I was done ...] So as I previously pointed out; *if* the community is already familiar with the candidate, thoroughly reviewed it for that full 72 hours, then if the RM replied to this file is broken with I'll fast-track only that fix and roll a final candidate with a shortened 24 hour final vote should put everyone in the frame of mind to review the revised candidate. But you can't ever shorten the net review time below three days :) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
So, you are saying option 2 is a reasonable choice, given that only the NOTICE/LICENSE files have changed one line here and there ? Thanks, Neha On Tue, Nov 29, 2011 at 5:34 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 11/29/2011 7:27 PM, William A. Rowe Jr. wrote: On 11/29/2011 4:00 PM, Neha Narkhede wrote: We would like to know if it is OK to either - 1. shorten the release VOTE for change to one non-code file 2. run 72 hour vote in parallel on the dev list as well as on general@ I've never seen a point to 2) to running serial votes. You need only 3 +1's (more +1's than -1's)... usually three mentors are enough to finish amoung the dev@ list, but announcing the vote (and its conclusion) on the general@ list seems entirely appropriate. If folks at general@ would like to have more input on the release, the ppmc dev@ list is really the best place to get involved. It is important to always allow 72 full hours. The reason is simple, we have participants in nearly every timezone, people who are here only on their own time, and more people who are here almost exclusively on work hours. 72 hours is long enough to accommodate them all, if they care to participate. [... trackpad arguing with me over whether I was done ...] So as I previously pointed out; *if* the community is already familiar with the candidate, thoroughly reviewed it for that full 72 hours, then if the RM replied to this file is broken with I'll fast-track only that fix and roll a final candidate with a shortened 24 hour final vote should put everyone in the frame of mind to review the revised candidate. But you can't ever shorten the net review time below three days :) --**--**- To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.orggeneral-unsubscr...@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.**orggeneral-h...@incubator.apache.org
Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
On 11/29/2011 7:50 PM, Neha Narkhede wrote: So, you are saying option 2 is a reasonable choice, given that only the NOTICE/LICENSE files have changed one line here and there ? Yes, if you let the 72 hour vote run through with a clear message that it will be rerolled with a short vote. If everyone says oh, it's a broken package and doesn't test further, then a 24 hour vote wouldn't be sufficient opportunity to review. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
