Inline On Wed, Jul 15, 2015 at 5:22 PM, Vinod Kumar Vavilapalli < vino...@hortonworks.com> wrote:
> I can understand these (sort of newish) questions from hbase-dev. We > already have a well laid-out release-management process. If people want to > learn more about how it works, please head over to > http://hadoop.apache.org/bylaws.html. > > In terms of 2.6.1 release management, it wasn’t stuck for lack of > volunteers for RM. I originally was driving it [1], and then Akira recently > volunteered too in a separate thread [2] (which I totally missed > participating in before), so we have enough help. > Right, but in that thread it looks like you were stymied sorting through the potential set of updates to apply to the patch release. That was the motivation behind my sharing a bit about HBase branch RMs. Totally fine if that's not something Hadoop wants to explore. I only offered it as a data point where another project avoids that problem with a different kind of RM focus. And, so, that's that FWIW > > It is clearly acknowledged there is a demand for 2.6.1, we now have to > figure out the mechanics, agreeing on a reasonable & common list of fixes > to start with. > > Thank you very much for this consideration! > Tx for the feedback so far @hbase-dev! I agree with Karthik earlier - > let’s continue the discussion in hadoop-dev in the release thread [1] for > 2.6.1. > > Thanks > +Vinod > > [1] Planning Hadoop 2.6.1 release > http://markmail.org/message/sbykjn5xgnksh6wg > [2] [DISCUSS] More Maintenance Releases http://s.apache.org/MMR > > On Jul 15, 2015, at 4:07 PM, Stack <st...@duboce.net<mailto: > st...@duboce.net>> wrote: > > Is there anyone interested in volunteering to run a 2.6.1 release (Akira?)? > You'd get some help (especially if the bar is set high and only critical > bug fixes are allowed in: i.e. no features, no 'perf' fixes, no jar > updates, and so on). > > St.Ack > > On Wed, Jul 15, 2015 at 3:07 PM, Chris Douglas <cdoug...@apache.org > <mailto:cdoug...@apache.org>> wrote: > > On Wed, Jul 15, 2015 at 2:07 PM, Sean Busbey <bus...@cloudera.com<mailto: > bus...@cloudera.com>> wrote: > Alternatively, why not appoint a Release Manager for the minor release > line > and then allow them to arbitrate when there's disagreement about > inclusion? > This has worked well in the HBase community. > > > Release managers aren't appointed in Hadoop. Any committer can RM a > release branch and encourage others to help with it. An RM can set the > bar arbitrarily, but an RC only becomes a release when a majority of > PMC votes approve it in a VOTE. -C > > On Wed, Jul 15, 2015 at 2:07 PM, Sean Busbey <bus...@cloudera.com<mailto: > bus...@cloudera.com>> wrote: > Why not just include all backwards compatible bug fixes? > > Alternatively, why not appoint a Release Manager for the minor release > line > and then allow them to arbitrate when there's disagreement about > inclusion? > This has worked well in the HBase community. > > On Wed, Jul 15, 2015 at 3:49 PM, Karthik Kambatla <ka...@cloudera.com > <mailto:ka...@cloudera.com>> > wrote: > > As I proposed in the other thread, how about we adopting the following > model: > > x.y.1 releases have all Blocker, Critical, Major bug fixes applied to > the > next minor release. > x.y.2 releases have all Blocker, Critical bug fixes applied to the next > minor release. > x.y.3 releases have all Blocker bug fixes applied to next minor release. > > Here I am assuming there are no security-fix-only or other urgent > releases. > > We could apply this approach for 2.7.x onwards, and do an adhoc 2.6 > release. > > On Wed, Jul 15, 2015 at 12:59 PM, Vinod Kumar Vavilapalli < > vino...@hortonworks.com<mailto:vino...@hortonworks.com>> wrote: > > Yeah, I started a thread while back on this one ( > http://markmail.org/message/sbykjn5xgnksh6wg) and had many offline > discussions re 2.6.1. > > The biggest problem I found offline was about what bug-fixes are > acceptable and what aren’t for everyone wishing to consume 2.6.1. > Given > the > number of bug-fixes that went into 2.7.x and into branch-2.8, figuring > out > a set of patches that is acceptable for everyone is a huge challenge > which > kind of stalled my attempts. > > Thanks > +Vinod > > > On Jul 15, 2015, at 8:57 AM, Sangjin Lee <sjl...@gmail.com<mailto: > sjl...@gmail.com>> wrote: > > Strong +1 for having a 2.6.1 release. I understand Vinod has been > trying > to > get that effort going but it's been stalled a little bit. It would > be > good > to rekindle that effort. > > Companies with big hadoop 2.x deployments (including mine) have > always > tried to stabilize a 2.x release by testing/collecting/researching > critical > issues on the release. Each would come up with its own set of fixes > to > backport. We would also communicate it via offline channels. During > the > hadoop summit, we thought it would be great if we all came together > and > create a public stability/bugfix release on top of 2.x (2.6.1 for > 2.6 > for > example) with all the critical issues fixed. > > Thanks, > Sangjin > > > On Tue, Jul 14, 2015 at 10:42 PM, Tsuyoshi Ozawa <oz...@apache.org<mailto: > oz...@apache.org>> > wrote: > > Thank you for the notification. Trying to back port bug fixes. > > - Tsuyoshi > > On Wed, Jul 15, 2015 at 3:45 AM, Sean Busbey <bus...@cloudera.com<mailto: > bus...@cloudera.com>> > wrote: > Hi Hadoopers! > > Over in HBase we've been discussing the impact of our > dependencies on > our > downstream users. As our most fundamental dependency, Hadoop > plays a > big > role in the operational cost of running an HBase instance. > > Currently the HBase 1.y release line supports Hadoop 2.4, 2.5, and > 2.6[1]. > We don't drop Hadoop minor release lines in minor releases so we > are > unlikely remove anything from this set until HBase 2.0, probably > at > the > end > of 2015 / start of 2016 (and currently we plan to continue > supporting > at > least 2.4 for HBase 2.0 [2]). Lately we've been discussing > updating > our > shipped binaries to Hadoop 2.6, following some stability testing > by > part > of > our community[3]. Unfortunately, 2.6.0 in particular has a couple > of > bugs > that could destroy HBase clusters should users decide to turn on > HDFS > encryption[4]. Our installation instructions tell folks to replace > these > jars with the version of Hadoop they are actually running, but not > all > users follow those instructions so we want to minimize the pain > for > them. > > Regular maintenance releases are key to keeping operational > burdens > low > for > our downstream users; we don't want them to be forced to choose > between > living with broken systems and stomaching the risk of upgrades > across > minor/major version numbers. Looking back over the three > aforementioned > Hadoop versions, 2.6 hasn't had a patch release since 2.6.0 came > out > in > Nov > 2014, when 2.5 had its last patch release as well. Hadoop 2.4 > looks > to > be a > year without a release[5]. On our discussion of shipping Hadoop > 2.6 > binaries, one of your PMC members mentioned that with continued > work > on > the > 2.7 line y'all weren't planning any additional releases of the > earlier > minor versions[6]. > > The HBase community requests that Hadoop pick up making > bug-fix-only > patch > releases again on a regular schedule[7]. Preferably on the 2.6 > line > and > preferably monthly. We realize that given the time gap since > 2.6.0 it > will > likely take a big to get 2.6.1 together, but after that it should > take > much > less effort to continue. > > [1]: http://hbase.apache.org/book.html#hadoop > [2]: http://s.apache.org/ReP > [3]: HBASE-13339 > [4]: HADOOP-11674 and HADOOP-11710 > [5]: http://hadoop.apache.org/releases.html > [6]: http://s.apache.org/MTY > [7]: http://s.apache.org/ViP > > -- > Sean > > > > > > -- > Karthik Kambatla > Software Engineer, Cloudera Inc. > -------------------------------------------- > http://five.sentenc.es > > > > > -- > Sean > > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
