community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Vesse <rve...@dotnetrdf.org>
Subject Re: How can we support a faster release cadence?
Date Mon, 10 Feb 2014 09:52:34 GMT
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





Mime
View raw message