On 11 February 2014 22:01, Andrea Pescetti <pesce...@apache.org> 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. >
