hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rottinghuis, Joep" <jrottingh...@ebay.com>
Subject RE: abandoning 22 - was: Content request for 0.20.205 Sustaining Release
Date Fri, 09 Sep 2011 17:41:47 GMT

-----Original Message-----
From: Eli Collins [mailto:eli@cloudera.com] 
Sent: Friday, September 09, 2011 10:03 AM
To: general@hadoop.apache.org
Subject: Re: abandoning 22 - was: Content request for 0.20.205 Sustaining Release


> MR1 is being maintained on 20x. In fact 20x is the only MR1 code that supports security
and disk failure handling. The MR1 code in 22 is a regression in some significant aspects
(features, performance, bugs) from the latest stable MR1 (204).

Eli, aside from the disk failure handling which is a new feature in 205 (not present in earlier
20x releases), could you please elaborate on which other significant aspects 22 would regress
from 20x? 

> My understanding of the way Apache operates is that you can't do things like "declare
blocks on upgrade paths". People can try to release updates to 21 or 22 (or some new tree).
Ie the decisions are made implicitly by where people invest cycles.

If a group of committers say that they'll commit to trunk, to 0.23 and to 0.20x, but not to
0.22, then in effect that is like to "declare a block on upgrade path" isn't it? The more
such commits that go in to other branches, but not the ones in between essentially is a declaration
of a block, because of the very regression argument you make.

I agree that nobody can be made to contribute to something they don't want, but does that
result into a split?
In other words, if a significant bug fix or feature goes into trunk and into 22, can developers
then simply say: "I'm not interested to put this into 23, you do this yourself if you want?".
Will that be tolerated or vetoed?



View raw message