hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Shvachko <shv.had...@gmail.com>
Subject Re: abandoning 22 - was: Content request for 0.20.205 Sustaining Release
Date Mon, 12 Sep 2011 12:37:43 GMT
> I benchmarked 22 v/s 20.xxx there was >5x difference and that was more than a year
ago.

Arun do you mind sharing the benchmarks that you ran?

Thanks,
--Konstatnin

On Fri, Sep 9, 2011 at 11:26 AM, Arun C Murthy <acm@hortonworks.com> wrote:
> Joep,
>
> On Sep 9, 2011, at 10:41 AM, Rottinghuis, Joep wrote:
>
>
> No one is going to block you from doing any work you want.
>
> All that is required is to have the work in trunk and subsequent branches i.e 0.23 (as
applicable) .
>
> The problem is that 0.22 hasn't seen major movement for almost a year since it was branched
and there is no incentive for lots of people to contribute - plus there is MRv2 which is completely
different beast (see the discussion that Eli pointed to).
>
> None of this is to say you shouldn't contribute or use 0.22, you move the project as
you wish by your contributions.
>
>>> 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?
>>
>
> I've talked to Konstantin about this.
>
> There is tonnes of performance work missing, including scaling work on JobTracker, CapacityScheduler
etc. There is work to add a ton of limits (counters, tasks, etc. etc.). Then there is operability
work such as JobHistory, handling logs etc. The last time I benchmarked 22 v/s 20.xxx there
was >5x difference and that was more than a year ago. Arguably some of the operability
work won't matter for small clusters, but you are welcome to make your own decisions.
>
> It's unfortunate we have landed here, but 22 branched almost a year ago and hence none
of this work was ported there since a branch implies critical bugs was supposed to go in.
That plus the problems with scaling MR1 which led to investment in MR1 is where we are. As
a result, there is no enthusiasm to contribute to MR1 from vast majority of devs given that
we've decided we won't support it.
>
>
>>> 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?
>>
>
> Again, no one is going to veto anything. As Eli said decisions are make by people's code.
>
> Arun
>
>

Mime
View raw message