On Fri, Nov 11, 2011 at 2:29 PM, Todd Lipcon <t...@cloudera.com> wrote: > 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. >
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 <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 > -- Todd Lipcon Software Engineer, Cloudera
