Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@community.apache.org
Received-SPF: pass (athena.apache.org: domain of
 stephen.alan.connolly@gmail.com designates 209.85.220.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CF1E4BBC.30257%rvesse@dotnetrdf.org>
References: <CF1E4BBC.30257%rvesse@dotnetrdf.org>
Date: Mon, 10 Feb 2014 10:35:42 +0000
Message-ID: 
 <CA+nPnMy=fEdYcRFbTTz=NPPQsaQ8Bic=KyZ+VDnwY5MKfTD-HQ@mail.gmail.com>
Subject: Re: How can we support a faster release cadence?
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
To: dev@community.apache.org
Content-Type: multipart/alternative; boundary=047d7b15fe87ce978a04f20ae6f4

--047d7b15fe87ce978a04f20ae6f4
Content-Type: text/plain; charset=ISO-8859-1

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
process...

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 if
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 after
72h with 3x+1 and my -1

That is how I could see a short vote working for a scheduled release
process...

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 <rvesse@dotnetrdf.org> wrote:

> 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.connolly@gmail.com>
> wrote:
>
> >On Monday, 10 February 2014, Upayavira <uv@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.connolly@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
>
>
>
>
>

--047d7b15fe87ce978a04f20ae6f4--