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
