community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: How can we support a faster release cadence?
Date Tue, 11 Feb 2014 22:38:11 GMT
On 11 February 2014 22:01, Andrea Pescetti <> wrote:

> Jim Jagielski wrote:
>> One reason for the 72hour rule is to ensure that no PMC
>> member feels disenfranchised. ...
>> PMCs are *inclusive*. The processes and procedures are
>> designed to maintain that inclusivity.
> This is not 100% incompatible with 12-hour votes.
> Our current rules assume that the PMC as a group is not immediately
> responsive, so they make provisions for the process to be inclusive. But a
> vote can (quite obviously, I'd say, even if I'm not quite experienced) be
> considered closed as soon as all PMC members have voted, and this can
> happen earlier than the 72 hours have elapsed.

You don't even need to go to 100% though obviously it is more polite (read
inclusive) to do so. If the PMC has N members and N > 6 then once (N/2+1)
PMC members have voted on a release, because you cannot veto a release
vote, then technically the release vote has passed...

I am not saying that it is polite, but simply recognising the fact that if
the release manager wants to go ahead with the release, even if all the
remaining (N/2-1) PMC members vote -1 the release manager can still put the
release out (though it would be a very stubborn release manager to push
such a contentious release)

> Sure, this is virtually impossible in the project I'm chairing, where I've
> never seen a vote with 100% participation from the PMC. But other projects
> are different. If a PMC is really determined to have shorter voting
> windows, they will be equally determined to vote as soon as possible and
> thus shrink the voting window, by closing the vote as soon as everybody has
> voted. If they can make it in 12 hours, this will be an inclusive 12-hour
> voting window.
> Regards,
>   Andrea.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message