hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.
Date Fri, 11 Nov 2011 06:31:20 GMT
Hey guys,

HDFS-2246 is not a fix, it's a non-trivial performance optimization.
The roadmap page is pretty clear..  "Point releases are made to fix
critical bugs. They do not introduce new features or make other
improvements other than fixing bugs".

I'm not opposed to the change, I'm just pointing out that we agreed to
develop trunk first, and we agreed to follow the release policies for
the sustaining branch. I don't see why we can't honor those
agreements, ie why not post a patch for trunk first and then backport
it to 206? Reasonable?

Thanks,
Eli

On Thu, Nov 10, 2011 at 9:58 PM, Suresh Srinivas <suresh@hortonworks.com> wrote:
> Eli,
>
> As Jitendra indicated in the jira, this was originally supposed to be part
> of 0.205. Due to time crunc, we could not get this done in 0.205. This can
> be turned off by a flag and only can be enabled by users who want to use
> the functionality. Given that, I feel it is okay to go into 0.205.1.
>
> I agree it would be good to have a trunk patch for this and make it part of
> 0.23.
>
> Regards,
> Suresh
>
> On Thu, Nov 10, 2011 at 4:32 PM, Eli Collins <eli@cloudera.com> wrote:
>
>> Hey Matt,
>>
>> Is HDFS-2246 slated for 0.20.205.1?  Given that it's not a bug and is
>> non-trivial it seems better suited for 206 than a point release. Also,
>> per the sustaining roadmap - http://wiki.apache.org/hadoop/Roadmap -
>> "Only functionality already committed to trunk should be submitted to
>> a sustaining release." and this functionality does not yet have a
>> patch for trunk yet (let alone committed).
>>
>> Thanks,
>> Eli
>>
>> On Fri, Nov 4, 2011 at 5:56 PM, Matt Foley <mattf@apache.org> wrote:
>> > Hi all,
>> > I propose to make a 0.20.205.1 candidate soon, with the following sets of
>> > patches:
>> >
>> >   - deficiencies in HBase support, pointed out by the HBase team and
>> others
>> >   - deficiencies in webhdfs support on secure clusters
>> >   - a couple last-minute fixes submitted to branch-0.20-security-205 that
>> >   were too late to be included in 205.0
>> >
>> > If you would like other patches included, and you feel it is appropriate
>> to
>> > have them in 205.1 rather than waiting for 206.0, please declare them by
>> > setting the "Target Versions" field in their Jiras, and they will receive
>> > due consideration, assuming that the proposed patch is actually
>> > contributed, tested, reviewed, approved, and committed
>> > to branch-0.20-security-205 by the freeze date :-)
>> >
>> > I would like to make the rc0 candidate next Friday, so I propose to
>> declare
>> > 205.1 code freeze at noon, PST, Friday 11 Nov.  If this is a problem for
>> > anyone, please let me know.
>> >
>> > Thank you, and best regards,
>> > --Matt (Release Manager)
>> >
>>
>

Mime
View raw message