+1 for the idea of maintenance releases. Considering the amount code changes done in trunk and branch-2, cherry-picking may not be easy and straight forward in all issues.
I would love to help in cherry-picking the fixes and reviewing them. I would also love to help in release process. Regards, Vinay On Mon, Jun 22, 2015 at 9:49 PM, Allen Wittenauer <a...@altiscale.com> wrote: > > If 2.6 is the target, someone will have to verify that any > cherry-picked patches actually work with JDK6 since the PMC voted to > officially kill backward compatibility in a minor release. It’s going to be > easier and probably smarter to fix 2.7 if that’s really desired. [1] > > Frankly, I’d rather see effort spent on stabilizing trunk and > ditching the now broken branch-2. We’re approaching the 4 year anniversary > of 0.23.0’s release (which later begat 2.x, which is already past the 3 > year mark). It’s hard to claim health when its been so long since a branch > off of trunk was cut and turned into something official. > > [1] Kengo and I are hard at work getting multiJDK testing working in > Yetus, but it’s not quite ready for prime time. :( It could certain help > here, but… it’s not very stable yet. > > On Jun 22, 2015, at 7:50 AM, Karthik Kambatla <ka...@cloudera.com> wrote: > > > Thanks for starting this thread, Akira. > > > > +1 to more maintenance releases. More stable upstream releases avoids > > duplicating cherry-pick work across consumers/vendors, and shows the > > maturity of the project to users. > > > > I see value in backporting blocker/critical issues, but have mixed > feelings > > about doing the same for major/minor/trivial issues. IMO, every commit > has > > non-zero potential to introduce other bugs. Depending on the kind of fix > > (say, documentation), it might be okay to include these non-critical > fixes. > > One approach could be to allow all bug fixes for 2.x.1, blocker/critical > > for 2.x.2, blocker for 2.x.3 (or something along those lines) to ensure > > increasing stability of maintenance releases? > > > > I am also +1 to any committer picking up RM duties for a maintenance > > release. It is healthy to have more people participate in the release > > process, so long as we have some method to maintenance release madness. > > > > A committer (who is not yet a PMC member) could be a Release Manager, but > > his vote is not binding for the release. I RM-ed the 2.5.x releases as a > > committer. RM-ing a release and voting non-binding could be a good way to > > remind the PMC to include the committer in PMC :) > > > > Cheers > > Karthik > > > > On Mon, Jun 22, 2015 at 4:36 AM, Tsuyoshi Ozawa <oz...@apache.org> > wrote: > > > >> Hi Akira, > >> > >> Thank you for starting interesting topic. +1 on the idea of More > >> Maintenance Releases for old branches. It would be good if this > >> activity is more coupled with Apache Yetus for users. > >> > >> BTW, I don't know one of committers, who is not PMC, can be a release > >> manager. Does anyone know about this? It's described in detail as > >> follows: http://hadoop.apache.org/bylaws#Decision+Making > >> > >>> Release Manager > >>> A Release Manager (RM) is a committer who volunteers to produce a > >> Release Candidate according to HowToRelease. > >>> > >>> Project Management Committee > >>> Deciding what is distributed as products of the Apache Hadoop project. > >> In particular all releases must be approved by the PMC > >> > >> Thanks, > >> - Tsuyoshi > >> > >> On Mon, Jun 22, 2015 at 6:43 PM, 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 > >
