hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: [VOTE] Release candidate 0.20.203.0-rc0
Date Sun, 01 May 2011 02:18:41 GMT
On Sat, Apr 30, 2011 at 7:17 AM, Owen O'Malley <omalley@apache.org> wrote:
> On Fri, Apr 29, 2011 at 7:21 PM, Eli Collins <eli@cloudera.com> wrote:
>
>> I took a quick look at the changes in the branch
>
>
> Thanks for taking a look. Please continue to inspect and test out the
> release and vote. I'm really excited that we'll have a release that has
> security and the "fred" user limits. Users desperately need these
> improvements. Furthermore, it is really important that Hadoop gets back on
> to a regular release cycle with releases coming out frequently. The current
> stable release of 0.20.2 was released a year ago, which is much much too
> long.
>

Agree.  Is branch-0.20 dead now? Ie the 20.3 and 20.4 fix versions
will never be released?  Are all the patches that have been committed
there since 0.20.2 (expecting that they'd be released) in
branch-0.20-security-203?  Users that saw jiras closed out with issues
committed to branch-0.20 with fix version 20.3 probably expect those
come out in this release.

>> How do we ensure future releases won't violate compatibility with
>> respect to this release?
>
>
> We are still in catchup mode in terms of making sure that everything gets
> committed to trunk. Of course our users will correctly complain if the later
> releases have regressions relative to this release. Thanks for pointing out
> the issue.
>

Seems like we need to do this before releasing 0.20.203 to prevent
blocking the upcoming 0.22 release, due to it being a regression
against the stable release (the sooner a release from trunk can
replace a 0.20 based release the better).

>
>> Do we plan to have jiras with patches against
>> trunk for these changes, at least for the set of changes that affect
>> public APIs?
>
>
> Yes, I'll work on ensuring the necessary patches get applied to trunk.
>

Awesome, thanks.

>
>> If so, should that come first?
>>
>
> The most import question is this release candidate a usable replacement and
> improvement on the current stable release 0.20.2. I believe it is a huge
> improvement and should be released.
>

Definitely a huge improvement, thanks for all the work. I had a
specific concern that it might block 0.22, and a general concern that
we don't want to set a precedent of releasing code that didn't go
through the normal code change (patch review and vote on jira/list).
Thank you for addressing this via getting the patches on trunk.

Thanks,
Eli

Mime
View raw message