Realistically I have rarely been involved in a project where the vote comes out of the blue. Projects have typically already discussed whether to move ahead with a release on the dev list in advance of the vote so I've always known the vote was coming. While any project member can propose a release candidate and call a vote I'd expect a well managed project to do some level of advance coordination on this.
However regardless of whether the vote is scheduled/known in advance or not the fact still remains that the window is very short. It makes the assumption that the schedules of the people voting are regular which is almost certainly untrue, the amount of time people can give to a project varies over time due to everyone's unique personal circumstances. There are also various ways I could imagine completely missing a 12hr voting window regardless of timezone and usual availability in the scheduled window e.g. being on a long haul flight with no internet access (or costly internet access). It also assumes that all a reviewer does is the basics of checking signatures, LICENSE, NOTICE and builds. What about people who already carry out more substantial reviewing? e.g. running the release candidates against their companies internal products. This is a process that may take substantial time and potentially involve coordinating with various parts of a reviewers work organisation that the reviewer may have no control over how long it takes for this to happen. Now maybe if an organisation is already doing internal builds against SNAPSHOTs and keeping close tabs on development this issue goes away but perhaps I work in an organisation that does not have sufficient infrastructure to support doing this on a regular basis, management refuses to use development builds etc. Certainly I agree that there are things that can be done to make parts of the review process much easier on reviewers e.g. tools for automatically checking signatures, comparing source distributions with the VCS tags etc. but they don't necessarily solve all the issues. The 12hr window idea also assumes that there will be no contention over the release candidate and that the person who is acting at the release manager is able to be awake & accessible for the entire 12hr window to take account of any issues raised and cancel/release as appropriate at the end of the window. The basic issue here is ultimately one of volunteer time, even if I knew that the vote was always coming at the same time each week/month/arbitrary interval there is no way that I could always guarantee I had the time to review it given only a 12hr window. So to repeat Upayavira's point I end up being excluded from the votes, maybe that is not the end of the world if the next vote is only a week away but it ultimately removes the flexibility and inclusiveness that the current 72hr window gives me. Rob On 10/02/2014 08:30, "Stephen Connolly" <stephen.alan.conno...@gmail.com> wrote: >On Monday, 10 February 2014, Upayavira <u...@odoko.co.uk> wrote: > >> >> >> On Sun, Feb 9, 2014, at 06:40 AM, Marvin Humphrey wrote: >> > On Sat, Feb 8, 2014 at 3:26 PM, Stephen Connolly >> > <stephen.alan.conno...@gmail.com <javascript:;>> wrote: >> > > 72h for a vote is not a hard and fast rule (you just need a good >> reason for >> > > why you are going shorter and from what I have seen, the board would >> > > probably be ok as long as protections are put in place to safeguard >>the >> > > community) >> > >> > By now, I think that we've demonstrated in this thread that scheduled >> > votes with a small window (12-24 hours) are practical. >> >> Have we? >> >> I don't believe anyone has expressed the real justification for a 72hr >> window, which is to enable the vote to be *inclusive*. That is, >> inclusive of people who don't live in the same timezone, and who perhaps >> don't work on the codebase full time. >> >> Yes, a 12hr window might make it possible for everyone to have at least >> 4 waking hours in that window, but what if that is your 4hrs of taking >> your kids to school, or cooking dinner for the family. Or if they >> contribute in their spare time, and that 4hrs is whilst they are at >> work. If the project chooses that particular 12hr window as a fixed >> thing, it effectively excludes you from the vote. > > >But this is a *scheduled* vote... If you know that it is something you >*want* to have a chance to vote on, you have sufficient time to ensure the >vote is extended in order for you tiger your say. > >IMHO 72h is needed *when you don't know that there will be a vote*... This >would be a different case... Though I ack that I had only thought this and >not articulated it prior > > >> I am in no way attempting to argue that 72hrs votes is the only way to >> achieve this particular aim, but I do not consider this issue as >> addressed in any way in this thread yet. So: >> >> If we are going to shorten release vote durations, how do we ensure >> inclusivity, both of current, and potential future contributors, >> irrespective of timezone, work pattern, etc? >> >> Upayavira >> > > >-- >Sent from my phone
