> From: Todd Lipcon <t...@cloudera.com> > Calling this a "critical fix" for HBase is a bit strange as 99.9% of > the HBase installs out there do not use it. Trend Micro and Facebook > are the only ones I'm aware of that do.
It would be more accurate to say we are running it in one production installation, but - have questions as to the performance benefits we will actually see - won't be able to use it in a deployment that requires stronger assurance > And the patch as it stands today has a very suspect security model... Agreed. In my opinion, this is a useful option to provide, but off by default, and isn't a critical fix. Nothing is broken. Call it "a performance optimization option". Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) ----- Original Message ----- > From: Todd Lipcon <t...@cloudera.com> > To: common-dev@hadoop.apache.org > Cc: > Sent: Friday, November 11, 2011 5:29 PM > Subject: Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 > Nov. > > On Fri, Nov 11, 2011 at 1:29 AM, Matt Foley <mfo...@hortonworks.com> > 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. > > Calling this a "critical fix" for HBase is a bit strange as 99.9% of > the HBase installs out there do not use it. Trend Micro and Facebook > are the only ones I'm aware of that do. And the patch as it stands > today has a very suspect security model... > > -Todd > > >> >> On Thu, Nov 10, 2011 at 10:31 PM, Eli Collins <e...@cloudera.com> > 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 > <sur...@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 > <e...@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 > <ma...@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) >>> >> > >>> >> >>> > >>> >> > > > > -- > Todd Lipcon > Software Engineer, Cloudera >
