www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Release Policy (72 hour topic)
Date Fri, 23 May 2014 21:13:13 GMT

On 5/23/14 12:44 PM, "Mark Thomas" <markt@apache.org> wrote:
>Spinning the 72-hour part off.
>I'm wondering if there is a correlation between the diversity of the PMC
>and the view that 72 hours is too long. My thinking is that if most of
>the PMC is from 2 or 3 companies then organising the necessary
>activities to enable votes to be made for a release to pass is fairly
>easy and 72 hours would look excessively long. I am primarily involved
>in Tomcat and Commons where (to my knowledge) no one company accounts
>for more than ~15% of the PMC and 72 hours does seem a reasonable time
>to give everyone a chance to vote.
>I'm not trying to say one PMC is 'better' than any other, just trying to
>get a better understanding of why one community would be happier with a
>much shorter voting period than the communities with which I am familiar.
>Alongside that I've been mulling over what sort of process could be used
>to shorten the vote and have come up with the following:
>For a given release:
>- the entire voting period (for all RCs) should be no shorter than
>  72 hours.
>- each RC will have a voting period of at least 24 hours unless the
>  RC vote is cancelled in which case there is no minimum
>- any PMC member may request an RC's voting period be extended to 72
>  hours without having to provide any justification
>- releases to address critical security vulnerabilities may reduce the
>  voting periods to any length at the discretion of the release manager

In a recent reply I mentioned trust, but I also think it is about patterns
and probability more than diversity.  Flex voters come from all geos, and
I think rarely see more than two votes from any one employer these days.
But we have found a "rhythm" or pattern.  And RC is posted and certain
individuals are way more likely to vote than others.  And so, after all of
the likely voters have voted, the probability we will find an important
issue in the remaining time is lower than the probability we will find
that issue after we announce the release.  1000's of folks download the
release, but we rarely get more than 2 votes from non-PMC members on
releases candidates.  Thus, a bug injected as the last commit before an RC
currently takes a minimum of 96 hours to be found (72 hours voting, plus
24 hour mirror propagation) if it isn't found in the first 24 or 36 hours
or so when most folks vote.  Add to that that Flex has never shipped a
release on one RC, that means that 3 more days per RC are added.  Then
after we find out about the bug, it is a minimum of 96 more hours until
the fix officially arrives in the customer's hands.  I think we can serve
our community better by having some leeway about how long to wait.  If it
were me, once most of the likely voters have weighed in on early RC's I'd
send a "last call" email before closing, but in later RCs if I'm just
adding a known issue to the RELEASE_NOTES, I'd probably ship it as soon as
I got 3 +1s and would rather ship it as soon as one person acknowledged
that I didn't screw up that change.

I really don't think there should be any minimum.  The PMC should work it
out to best serve their communities.  If you want to have weekly or twice
weekly releases, it is probably because your community is willing to roll
with injections because they trust you'll fix it soon.  We'll probably be
ship less often and provide longer vote windows for the main Flex SDK than
the alpha-level FlexJS releases.


To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message