hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@altiscale.com>
Subject Re: [DISCUSS] More Maintenance Releases
Date Mon, 22 Jun 2015 16:19:50 GMT

	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
View raw message