Thanks Allen for reminding me of supporting JDK6. If 2.6 is the target,
any commmiter needs to check a bug fix patch when cherry-picking it.
For trunk, I'm thinking we need to decide what we should do for release
3.x, in another thread. I'm okay to discuss it again.
On 6/23/15 01:19, Allen Wittenauer 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
