On 10 February 2014 16:29, Marvin Humphrey <mar...@rectangular.com> wrote:
> On Mon, Feb 10, 2014 at 5:36 AM, Jim Jagielski <j...@jagunet.com> wrote: > > A concern is that if the same person is RM, and the vote is always > > done at the same time (and so the 12 hour window never shifts, time- > > wise) then the vote will *always* favor those who are in the > > timezone of that vote. > > Fair point. Thanks for making it. > > Shifting the window regularly might conceivably compensate, but it would be > inconvenient and chaotic, disadvantaging everyone except for the most > highly > engaged inner core of developers. > > It may be that voting times under 24 hours are inherently unstable and > difficult to implement fairly. > > > One reason for the 72hour rule is to ensure that no PMC > > member feels disenfranchised... not all PMC members are in > > the same timezone and not all PMC members should be assumed > > to be paid to work on the code (and thus available 24/7 > > as it were). Longer vote times handle those cases. > > I see a predictable schedule as the key attribute which allows the shorter > time. IMO it's OK to for a community to ask people to make time on a > specific > day so long as that day is known well in advance. > > But I am concerned once again about what happens when a vote fails. If > there's another vote held right away, to my mind it would *also* have to be > predictably scheduled in order to justify the shorter window. I can > imagine > two options: > > * Only one vote per week. If it fails, the cycle is missed and we're on > to > the next. * A series of daily votes each beginning at the same hour, until one > passes. > Possibly each release cycle could have a max of two or three votes. > I think that any vote out of schedule needs to have at least 72h for vote joining by the PMC... So for example, if there is a critical security issue that needs a fix released... but the fix being voted on for 72h would lead to 3 days of zero-day exploits... well in that case I would see the PMC agreeing that they will prepare the RC and vote very quickly to release it... there would probably be notice on the private@ list asking for PMC members that are interested, and the patch to be released would likely be shared "out of band"... once all interested parties are happy that they will be able to vote then the patch gets applied and the vote called at the scheduled time, the 3 +1's cast and the vote gets closed. The important part, from the community PoV, in the above process (which need not be the only way) is that there was at least 72h notice for all interested parties to get involved. To my mind, weekly releases means that you either release on time or you burn a week. There are two ways to handle that: * Always have a revision that is releasable ready... i.e. it only gets cut as an RC if the automation says so * Drop the release for that week. Daily votes is just piling on the pain to the PMC, and you don't gain the feedback that you want as users have checked on the Wednesday (or whatever day they expect a new release) and seen none... not like they'll be polling waiting on the next one... OTOH I don't want to prescribe what PMCs should do. In the history of Jenkins there have been about 8-10 releases skipped (ie. where there was no release that week)... If you are skipping releases every week... then you are doing it wrong... and that is a different bad smell for the community to object to. -Stephen > > Marvin Humphrey >
