Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # general - Naming of Hadoop releases


Copy link to this message
-
Re: Naming of Hadoop releases
Eric Baldeschwieler 2012-03-20, 06:47
Lots of good stuff on this thread.   Todd, Chris and Todd have made great points.  (+1)

Doug, I think you have misdiagnosed the problem (in your comment below).  IMO the problem at the time of the creation of the 0.20.2xx was that the Hadoop community had not produced a stable release for years and none of 0.21, 0.22 or 0.23 were converging quickly to a stable release.  At the time, we had a lot of debate and concluded that 0.20.2xx was very much in the spirit of Apache.  We concluded that any committer is free to create any branch and can call a vote to release it if they choose.

Looking back, this open process has allowed us to make a lot of progress!  We've created a bit of naming messiness for sure, but let's look at the gains. The 0.20.2xx release is good enough that the PMC chose to promote it to Hadoop 1.0.  Further the 0.22 line is now good enough that ebay runs it in production and 0.23 continues to make great forward progress.  By allowing different contributors to pursue different agendas within the community, we have successfully produced stable releases and collected a lot of work within Apache Hadoop that was previously forced to live in private patch sets and branches.  We now may (or may not) agree on new naming for the other releases.  In the end, the community is better off with more choices and more progress.  This seems like a perfect blend of meritocracy and democracy.

Let's not discourage back porting and other contributions.  We have release masters, patch reviews and feedback to stop bad ideas and votes to choose between competing visions of what comes next.  Let's have fewer bylaws and allow messiness when needed.

E14
On Mar 19, 2012, at 4:18 PM, Doug Cutting wrote:

> On 03/19/2012 03:38 PM, Todd Lipcon wrote:
>> Unfortunately, I don't have a better solution in mind that resolves
>> the above problems - I just don't think it's tenable to combine a
>> policy like "anyone may make a release branch off trunk and claim a
>> major version number" with another policy like "you have to port a fix
>> to all intermediate versions in order to port a fix to any of them".
>> If a group of committers wants to make a release branch, then the
>> maintenance of that branch should be up to them.
>
> I don't think it's the case that anyone can create a new major version
> number.  Creation of new release branches should be an activity of the
> PMC, not individuals.  As such, the majority of the PMC implicitly or
> explicitly approves such branches and the PMC must responsibly deal with
> the ensuing results.  We should not operate as a fragmented community
> creating a fragmented, overlapping set of products.
>
> As I recall, when the 0.22 release branch was created it was intended by
> the PMC to be a release branch that followed 0.20 and preceded 0.23.
> Since then we as a PMC have acted inconsistently and now must deal with
> the consequences.
>
> We've already made an exception to our policies in releasing 0.20.20x
> and 0.22 that regresses from it in some areas.  We now need to decide
> whether we want to continue that exception by renaming 0.22 to 2.0 or
> not.  It does not look like we'll reach consensus on this.  That's
> unfortunate, but we still need to answer it.
>
> We also should decide whether we want to permit ourselves to get in this
> pinch again.  I think it's avoidable if in the future we only make
> releases that are consistent with our other policies.  Backports should
> be easier for intervening releases.  We might reasonably grandfather
> 0.22 as skippable for backports as it's too late to fix that now.
>
> Doug