hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: abandoning 22 - was: Content request for 0.20.205 Sustaining Release
Date Fri, 09 Sep 2011 18:08:00 GMT
On Fri, Sep 9, 2011 at 10:41 AM, Rottinghuis, Joep
<jrottinghuis@ebay.com> wrote:
>
>
> -----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?

Check out the MR jiras in the branch-20-security change log. There's a
ton of performance, feature and stability work. 22 doesn't have most
of this.


>
>> 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 release manager - not the developers - are responsible for and
have the final say as to what patches get merge to their branch.  If
the RM wants all this work they need to either corral the developers
to do the merging or do the merging themselves. In short, it's their
responsibility to get people to invest in the branch.

Thanks,
Eli

Mime
View raw message