incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
Date Wed, 30 Nov 2011 14:11:49 GMT
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.


- Leo

On Tue, Nov 8, 2011 at 9:44 PM, Leo Simons <> wrote:
> On Fri, Nov 4, 2011 at 3:54 PM, Benson Margulies <> wrote:
>> 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:
For additional commands, e-mail:

View raw message