As a heads up, this will require some tweaks in downstream projects. For example:
https://issues.apache.org/jira/browse/HIVE-2570 Currently I cannot use Hive with Hadoop 0.20.20#.0 because of this. Thanks. Alejandro On Fri, Nov 11, 2011 at 10:34 AM, Eli Collins <e...@cloudera.com> wrote: > Hey Matt, > > My understanding of introducing the new 4 part version scheme was to > provide stability. Eg if someone is running 0.20.205.0 wants to be > able to get just critical bug fixes (maybe they don't even use HBase) > to what they're running then they can use 205.1, .2 etc. If someone > running 205 wants something that's more than a critical bug fix (eg a > performance optimization like HDFS-2246) then they upgrade to the next > minor version (206), which still supports a path for people running > 205. This allows us to serve both users (those who want just critical > bug fixes to what they're running and those who want stuff like perf > improvements for HBase), while the plan of putting everything in the > point release serves one type of user at the expense of the other. > What's the disadvantage of putting this in 206? That can be released > soon as well right? According to the wiki it was supposed to branch > last month. > > Thanks, > Eli > > On Fri, Nov 11, 2011 at 1:29 AM, Matt Foley <mfo...@hortonworks.com> wrote: >> Hi Eli, >> The reason I am looking at HDFS-2246 for 205 is that I and a number of >> Hadoop and HBase community members really want 205 to have good support for >> HBase. This performance improvement turns out to be pretty important in >> order to actually have good support for HBase. In that sense, I'm inclined >> to consider it a critical fix. >> >> However, I think you have a very valid point about trunk support. Suresh, >> can we have a concurrent submission to trunk? >> >> 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? >> >> Thanks, and regards, >> --Matt >> >> >> 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) >>> >> > >>> >> >>> > >>> >> >
