hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: Release plans
Date Fri, 19 Feb 2010 02:12:29 GMT
On Thu, Feb 18, 2010 at 6:08 PM, Konstantin Shvachko <shv@yahoo-inc.com> wrote:
> On 2/18/2010 5:19 PM, Jeff Hammerbacher wrote:
>>
>> Do we have consensus around rebasing on 0.21? Anyone already testing on
>> 0.21
>> who would be upset if the current branch were to be retired?
>
> Rebasing 0.21 will further delay the release.
> In current 0.21 branch there is some 28 blockers,
> which will take a couple of weeks to fix.
> The rebased 0.21 will add to this more issues, and therefore
> more time. Based on the experience I had time to stabilize
> the release is measured in months rather than weeks.

I agree that we're probably talking months rather than weeks. However,
I see a lot of the stabilization time as a fixed cost regardless of
the number of changes. Certainly there is an O(n) component too, but I
don't think the stabilization time of a rebased 21 is double the
stabilization time of current 21. Maybe more like 30% more? Do you
disagree?

-Todd


> --Konstantin
>
>
>>
>> On Thu, Feb 18, 2010 at 5:02 PM, Owen O'Malley<omalley@apache.org>  wrote:
>>
>>> >  On Feb 18, 2010, at 3:06 PM, Jeff Hammerbacher wrote:
>>> >
>>> >    I think the community will step up to knock down some of the
>>>>
>>>> >>  blockers once we resolve what should be in the 0.21 release: the
>>>> >> current
>>>> >>  branch, or a rebase on trunk. Do you/Yahoo! have a preference
on
>>>> >> that
>>>> >>  front?
>>>> >>
>>>
>>> >
>>> >  Yahoo doesn't care. Even if we rebase the 0.21 branch, because of the
>>> >  timing, Yahoo will probably never deploy it. (It take months to push a
>>> >  release through QA and production testing, as I wrote the security
>>> > release
>>> >  will hit the pipeline this year (code complete in february, first
>>> >  integration cluster in april, on all production clusters by august).
>>> > Yahoo
>>> >  can't handle another big release until january 2011.
>>> >
>>> >  Personally, I'd prefer to rebase 0.21, especially after we have the
>>> > Maven
>>> >  story straightened out. Generating good poms would be a huge win for
>>> >  downstream projects.
>>> >
>>> >  One big concern is that backwards incompatibility is a big cost.
>>> > Especially
>>> >  if 0.21 (like 0.19) never gets wide deployment, I'd like to start a
>>> > vote
>>> >  that we don't make any API incompatible in 0.22 relative to 0.20.
>>> >
>>> >  -- Owen
>>> >
>
>

Mime
View raw message