hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Srinivas <sures...@yahoo-inc.com>
Subject Re: [VOTE] Release candidate 0.20.203.0-rc1
Date Wed, 04 May 2011 22:41:00 GMT
Here is a snippet from your blog -
http://www.cloudera.com/blog/2010/10/cdh3-beta-3-now-available/

------

Security Enhancements
As one of the primary contributors and largest production users of Hadoop,
Yahoo! publishes the source tree for the version of Hadoop that they run on
their production clusters. We are pleased to announce that we have merged
Yahoo┬╣s source tree into CDH3b3. This merge brings many improvements
developed at Yahoo! into CDH, including improvements for MapReduce
scalability on 1000+-node clusters and several new tools for benchmarking
and testing Hadoop.
------

It would be great, if you can list how many of 192 changes were reviewed and
became part of CDH.

Your -1 vote essentially blocks the changes that are already available in
CDH to be available from Apache open source!


On 5/4/11 3:30 PM, "Todd Lipcon" <todd@cloudera.com> wrote:

> With Cloudera hat on, I agree with Eli's assessment.
> 
> With Apache hat on, I don't see how this is at all relevant to the task at
> hand. I would make the same arguments against taking CDH3 and releasing it
> as an ASF artifact -- we'd also have a certain amount of work to do to make
> sure that all of the patches are in trunk, first. Additionally, I'd want to
> outline what the inclusion criteria would be for that branch.
> 
> -Todd
> 
> On Wed, May 4, 2011 at 3:24 PM, Eli Collins <eli@cloudera.com> wrote:
> 
>> With my Cloudera hat on..
>> 
>> When we went through the 10x and 20x patches we only pulled a subset
>> of them, primarily for security and the general improvements that we
>> thought were good.  We found both incompatible changes and some
>> sketchy changes that we did not pull in from a quality perspective.
>> There is a big difference between a patch set that's acceptable for
>> Yahoo!'s user base and one that's a more general artifact.
>> 
>> When we evaluated the YDH patch sets we were using that frame of mind.
>>  I'm now looking it in terms of an Apache release. And the place to
>> review changes for an Apache release is on jira.
>> 
>> CDH3 is based on the latest stable Apache release (20.2) so it doesn't
>> regress against it.  I'm nervous about rebasing future releases on 203
>> because of the compatibility and quality implications.
>> 
>> Thanks,
>> Eli
>> 
>> 
>> On Wed, May 4, 2011 at 3:06 PM, Suresh Srinivas <sureshms@yahoo-inc.com>
>> wrote:
>>> Eli,
>>> 
>>> How many of these patches that you find troublesome are in CDH already?
>>> 
>>> Regards,
>>> Suresh
>>> 
>>> 
>>> On 5/4/11 3:03 PM, "Eli Collins" <eli@cloudera.com> wrote:
>>> 
>>>> On Wed, May 4, 2011 at 10:31 AM, Owen O'Malley <omalley@apache.org>
>> wrote:
>>>>> Here's an updated release candidate for 0.20.203.0. I've incorporated
>> the
>>>>> feedback and included all of the patches from 0.20.2, which is the last
>>>>> stable release. I also fixed the eclipse-plugin problem.
>>>>> 
>>>>> The candidate is at:
>> http://people.apache.org/~omalley/hadoop-0.20.203.0-rc1/
>>>>> 
>>>>> Please download it, inspect it, compile it, and test it. Clearly, I'm
>> +1.
>>>>> 
>>>>> -- Owen
>>>> 
>>>> While rc2 is an improvement on rc1, I am -1 on this particular rc.
>>  Rationale:
>>>> 
>>>> This rc contains many patches not yet committed to trunk. This would
>>>> cause the next major release (0.22) to be a feature regression against
>>>> our latest stable release (203), were 0.22 released soon.
>>>> 
>>>> This rc contains many patches not yet reviewed by the community via
>>>> the normal process (jira, patch against trunk, merge to a release
>>>> branch). I think we should respect the existing community process that
>>>> has been used for all previous releases.
>>>> 
>>>> This rc introduces a new development and braching model (new feature
>>>> development outside trunk) and Hadoop versioning scheme without
>>>> sufficient discussion or proposal of these changes with the community.
>>>> 
>>>> We should establish new process before the release, a release is not
>>>> the appropriate mechanism for changing our review and development
>>>> process or versioning .
>>>> 
>>>> I do support a release from branch-0.20-security that follows the
>>>> existing, established community process.
>>>> 
>>>> Thanks,
>>>> Eli
>>> 
>>> 
>> 
> 
> 


Mime
View raw message