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
