community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: How can we support a faster release cadence?
Date Wed, 12 Feb 2014 18:46:24 GMT
On 2/11/14, 11:04 PM, Marvin Humphrey wrote:
> On Tue, Feb 11, 2014 at 7:56 AM, Joseph Schaefer <> wrote:
>> The core question for me is do we want to continue
>> down this path of attempting to be all things to
>> all people with no common culture or values or processes,
>> or is there a floor somewhere.  If there is, where
>> should it be?
> To my mind, the distinguishing characteristic of Apache releases is that they
> are vetted by the community before distribution to the general public[1].  The
> implementation details matter, but that's what's fundamental.

That is only part of it and it is really just a side effect of the
"common culture or values or processes" that Joe is referring to. 
What is primary is that a release is an action of the community. 
Vetting the final artifacts is just the last step in the process. 
The traditional "Apache Way" of releasing goes more or less like this:

0) Some community member says, "I think we should cut a release some
time soon.  We should finish blah, punt bleh and call it x.y.z."
1) Some discussion ensues on the dev list.  Consensus emerges (or
not, maybe punting bleh is anathema to some) and someone steps up to
RM the release.
2) Beloved and beleaguered RM develops a release plan (sometimes a
Wiki, sometimes just mail threads, sometimes just marking issue
tracker tickets).
3) People work on finishing blah, random cleanup stuff, getting the
most excellent Rube Goldberg machine the project uses to build
artifacts to create a clean distro package.
4) Courageous RM creates an RC, including release notes, and the
community VOTEs  (this step may be repeated several times :)

I know this looks old-fashioned, even downright anachronistic to
"push-hourly-from-CI" people; but deciding *what* to release *as a
community* is an important responsibility of ASF PMCs.  Putting
things on a rigid schedule basically skips this step, which, IMHO is
a core part of our common culture and values.

I am not claiming that all of the steps above have to be performed
all the time or in the same way or on any prescribed timeline; but I
strongly agree with Joe that we should agree on some basic
principles that whatever diverse development and release processes
we embrace have to conform to.  To me, one of those principles is
that *releases are community actions*, which means that it is the
responsibility of the PMC to assess and memorialize the consensus of
the community to proceed with a release.  VOTEs have worked well for
that up to now.  Another principle is what Upayavira and Jim have
pointed out: *our communities are inclusive* - you don't have to
work for a certain employer, live in a certain timezone or belong to
any special group or have any non-publicly-earned credentials to
participate.  That makes short-duration VOTEs problematic.  Maybe
not impossible, but problematic.  The idea below of signalling
intent early could be helpful here - get people involved in
reviewing content of releases before the final tags / artifacts are
cut.  That way VOTE-ing can involve less work and the input of
community members not able to VOTE in time can still be taken into

> I came into this discussion with the belief that scheduling the date of a
> release well in advance would allow for adequate community review to take
> place within a smaller window, especially since frequent releases yield small,
> incremental deltas which are easy to review.
> I don't see this workflow as foreign or revolutionary at all, but
> instead as faithful to the Apache Way both in spirit and letter.
> Marvin Humphrey
> [1] I'm paraphrasing someone else's quote.  Regrettably, it was on a private
>     list so I can't link to their post or give proper credit.

View raw message