I'm not sure we qualify as a big user, but FWIW, we are upgrading to a Hadoop based on 2.6.0 ( with our own application of critical bugfix patches that went in on branch-2 later ) over at Salesforce.
2.7.0 and up are scary because 2.7.0 was tagged as not ready for production. There's a "may eat your data" sign hanging over 2.7.0 and all subsequent releases and points along the branch-2 history. Even using 2.6.0 comes with some trepidation because we know the HDFS encryption feature added in that release will destroy any HBase installation if it is turned on. On Tue, Jun 23, 2015 at 11:55 AM, Karthik Kambatla <ka...@cloudera.com> wrote: > On Tue, Jun 23, 2015 at 10:30 AM, Andrew Wang <andrew.w...@cloudera.com> > wrote: > > > There's no reason we have to choose 2.6 xor 2.7. If we have willing RMs > and > > enough PMCs who will vote on releases, there's no reason we can't > maintain > > both. > > > > However, based on the discussion at Hadoop Summit with Yahoo and Twitter, > > their interest is primarily in 2.6, and Daryn mentioned the need to get > 2.6 > > stable before they can move to 2.7. So, if we want to help out these big > > users, it seems like we should focus on maintaining 2.6. > > > > It would be nice to hear from the big users on the topic. > > They are already on 2.6 and some of them have already done a bunch of > backports. Given it will take us a month or two (based on past experience) > to get the first release out, it is not clear to me if we should start > focusing on 2.6 or 2.7. But again, as you say, if there are people willing > to RM these releases, I see value in improving both lines. > > > > > > Allen also brought up the issue of JDK6. I see a few options (ranked best > > to worst in my eyes): > > > > * Add multi-JDK support to test-patch > > * Keep using JDK7 for precommit, and keep an eye on a nightly JDK6 run > > * Drop support for JDK6 in 2.6.x, since no one is using it anymore > > > > #3 is the most easiest and probably fine for 95% of users, but doing a > big > > compat break is not how I'd want to kick off a stable release line. #2 > > isn't too bad if we don't want to wait for #1. > > > > Finally, an issue that Karthik mentioned at Hadoop Summit is that > > CHANGES.txt maintenance becomes a huge burden when doing backports after > > the initial commit. e.g. if I was backporting something to branch-2.6, > I'd > > potentially need to update CHANGES.txt in trunk, branch-2, branch-2.7 to > > move the JIRA # to the right version. If we either automated or dropped > > CHANGES.txt, the process would be much smoother. > > > > +1 for ditching CHANGES.txt. > > I reached out to Allen recently. He wanted to clean up his scripts more > before dropping CHANGES.txt altogether. Should we target 2.8 for this? > > > > > > Best, > > Andrew > > > > On Tue, Jun 23, 2015 at 6:05 AM, Akira AJISAKA < > ajisa...@oss.nttdata.co.jp > > > > > wrote: > > > > > Thanks Tsuyoshi for the comment. > > > > > > Targeting to 2.7 looks good to me, however, I'd like to maintenance > > > branch-2.6 also. It's only about a half year since 2.6.0 was released. > > > I don't want to abandon relatively new branches. > > > > > > > > > On 6/23/15 16:05, Tsuyoshi Ozawa wrote: > > > > > >> Thank you for clarification, Karthik. > > >> > > >> I'd also like to work on stable release management with community. > > >> > > >> I'm thinking of speedy release against <next version - 1> branch for > > >> making community feedback faster (e.g. current next version is 2.8, so > > >> cherry-picking to 2.7 and releasing it are useful work for users). > > >> > > >> I know that code base of 2.7.1 is now freezing currently, I'd love to > > >> work from 2.7.2 release if possible. > > >> > > >> Cheers, > > >> - Tsuyoshi > > >> > > >> On Tue, Jun 23, 2015 at 5:02 AM, Colin P. McCabe <cmcc...@apache.org> > > >> wrote: > > >> > > >>> +1 for creating a maintenance release with a more rapid release > > >>> cadence and more effort put into stability backports. I think this > > >>> would really be great for the project. > > >>> > > >>> Colin > > >>> > > >>> On Mon, Jun 22, 2015 at 2:43 AM, Akira AJISAKA > > >>> <ajisa...@oss.nttdata.co.jp> wrote: > > >>> > > >>>> Hi everyone, > > >>>> > > >>>> In Hadoop Summit, I joined HDFS BoF and heard from Jason Lowe that > > >>>> Apache > > >>>> Hadoop developers at Yahoo!, Twitter, and other non-distributors > work > > >>>> very > > >>>> hard to maintenance Hadoop by cherry-picking patches to their own > > >>>> branches. > > >>>> > > >>>> I want to share the work with the community. If we can cherry-pick > bug > > >>>> fix > > >>>> patches and have more maintenance releases, it'd be very happy not > > only > > >>>> for > > >>>> users but also for developers who work very hard for stabilizing > their > > >>>> own > > >>>> branches. > > >>>> > > >>>> To have more maintenance releases, I propose two changes: > > >>>> > > >>>> * Major/Minor/Trivial bug fixes can be cherry-picked > > >>>> * (Roughly) Monthly maintenance release > > >>>> > > >>>> I would like to start the work from branch-2.6. If the change will > be > > >>>> accepted by the community, I'm willing to work for the maintenance, > > as a > > >>>> release manager. > > >>>> > > >>>> Best regards, > > >>>> Akira > > >>>> > > >>> > > > > > > > > > -- > Karthik Kambatla > Software Engineer, Cloudera Inc. > -------------------------------------------- > http://five.sentenc.es > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
