Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # dev - [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.


Copy link to this message
-
Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.
Jitendra Pandey 2011-11-23, 19:10
The trunk, 206 patches for HDFS-2246 have been committed. I think it makes
sense to commit it to 205.1 as well for following reasons (most of it has
already been mentioned)
a) We intended this patch for 205, but couldn't finish in time. Now that
205.1 branch is still not cut, we could get this in.
b) This is not a very risky change. Most of it is new code and will be
disabled by default the feature will be disabled.
c) The performance benefits are very good, as reported by Todd on the jira.
Hbase installations will significantly benefit from it.

On Mon, Nov 14, 2011 at 1:44 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:

> On Fri, Nov 11, 2011 at 2:29 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> > On Fri, Nov 11, 2011 at 1:29 AM, Matt Foley <[EMAIL PROTECTED]>
> wrote:
> >
> >>
> >> Also, I believe in the HDFS-2246 Jira, Todd requested extra time to
> review,
> >> due to commitments at Hadoop World.  Todd, would Monday be sufficient
> extra
> >> time, so as not to slow down the anticipated release schedule too much?
> >>
> >
> > Yes, I will probably have time to review it by Monday. But the
> > review-time concern is separate from the concern about which version
> > this should go into.
> >
>
> Reviewing this now... though I still think it shoudl target 0.20.206,
> not 0.20.205.1.
>
> -Todd
>
> >
> >>
> >> On Thu, Nov 10, 2011 at 10:31 PM, Eli Collins <[EMAIL PROTECTED]> wrote:
> >>
> >>> 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 <
> [EMAIL PROTECTED]>
> >>> 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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> 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