incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
Date Wed, 30 Nov 2011 14:21:15 GMT
On 30 November 2011 14:11, Leo Simons <> 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 <> wrote:
>> On Fri, Nov 4, 2011 at 3:54 PM, Benson Margulies <> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message