hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinayakumar B <vinayakum...@apache.org>
Subject Re: [DISCUSS] More Maintenance Releases
Date Mon, 22 Jun 2015 17:19:13 GMT
+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 <aw@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 <kasha@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 <ozawa@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
> >> <ajisakaa@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message