On 2/11/14, 11:04 PM, Marvin Humphrey wrote: > On Tue, Feb 11, 2014 at 7:56 AM, Joseph Schaefer <joe_schae...@yahoo.com> > 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 account. Phil > > 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. >
