community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Vesse <>
Subject Re: How can we support a faster release cadence?
Date Mon, 10 Feb 2014 11:50:21 GMT

Your expanded description of the proposed short release vote process
addresses all of my concerns, thanks for taking the time to expand on this

I think that perhaps saying I am unavailable for the vote but want to vote
should not necessarily be an automatic -1 and perhaps be a 0 instead.

With a large enough PMC likely there will be enough active people to
obtain the necessary +1's in the 12hr window regardless of a few people
being unavailable and a PMC may not want certain peoples expressed
intention to vote at some point in the future to block the ability to move
ahead with the release.  However I see this as being something each
project would decide upon, smaller projects may want it to be a -1 while a
larger project may want it to either be a 0 or not count as a vote.

Also I think that projects will need to have some mechanism to say that
certain releases will still be subject to the longer 72hr vote window
regardless of whether they normally use a shorter window e.g. those that
include known breaking changes or integrate major feature branches.

In general I think it is important to emphasise as you have done that all
aspects of this should be discussed and tailored on a per-project basis to
account for the PMC and community of specific projects.


On 10/02/2014 10:35, "Stephen Connolly" <>

>Well I see this as something that a PMC wanting to move faster would have
>to weigh up and justify to the board.
>What I would like to see come out of this debate is a set of concerns that
>a PMC should find a way to address before they start a fast cadence
>I would expect that a proposed fast cadence process would have the support
>of a significant majority of both the PMC and committers.
>I would expect that a proposed fast cadence process would have a mechanism
>whereby interested parties could signal that they want to vote and will
>need an additional time window to have the opportunity... to my mind, such
>a signal would count as a -1 vote pending the actual vote.
>I would expect that a short window vote would only be allowed to proceed
>there are at least 3 +1 votes and no -1 votes... if there are -1 votes I
>would expect the vote to have to go to 72h
>Thus if I know there will be a vote tomorrow, but I will be out of
>communication due to a trans-pacific flight say, I could notify my intent
>to vote... that gets treated as a -1 until I actually cast my vote... thus
>the 12h shortcut is "vetoed" until my vote is cast.
>Things go wrong when I arrive at my destination, and it is 3 days before
>they return my laptop and let me connect to the outside world... in the
>interim, 3 other PMC members have voted +1 and the release went ahead
>72h with 3x+1 and my -1
>That is how I could see a short vote working for a scheduled release
>It would me more that the PMC says "as long as everyone is happy with
>running short releases, we will make short releases... but if anyone yells
>'stall the ball' then it's a 72h vote until they say 'nah it's grand go
>ahead'... and any contentious votes have to go 72h anyway"
>On 10 February 2014 09:52, Rob Vesse <> wrote:
>> Realistically I have rarely been involved in a project where the vote
>> comes out of the blue.  Projects have typically already discussed
>> 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
>> 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
>> 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
>> in an organisation that does not have sufficient infrastructure to
>> 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
>> the review process much easier on reviewers e.g. tools for automatically
>> checking signatures, comparing source distributions with the VCS tags
>> 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
>> 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
>> 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
>> 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"
>> wrote:
>> >On Monday, 10 February 2014, Upayavira <> wrote:
>> >
>> >>
>> >>
>> >> On Sun, Feb 9, 2014, at 06:40 AM, Marvin Humphrey wrote:
>> >> > On Sat, Feb 8, 2014 at 3:26 PM, Stephen Connolly
>> >> > < <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
>> >> > > probably be ok as long as protections are put in place to
>> >>the
>> >> > > community)
>> >> >
>> >> > By now, I think that we've demonstrated in this thread that
>> >> > votes with a small window (12-24 hours) are practical.
>> >>
>> >> Have we?
>> >>
>> >> I don't believe anyone has expressed the real justification for a
>> >> 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
>> >> don't work on the codebase full time.
>> >>
>> >> Yes, a 12hr window might make it possible for everyone to have at
>> >> 4 waking hours in that window, but what if that is your 4hrs of
>> >> 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
>> >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*...
>> >would be a different case... Though I ack that I had only thought this
>> >not articulated it prior
>> >
>> >
>> >> I am in no way attempting to argue that 72hrs votes is the only way
>> >> 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

View raw message