hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject [DISCUSSION] Adopt the Release Manager role for Hadoop
Date Tue, 04 May 2010 20:31:03 GMT
After 0.20 was branched in 2008, there have been no releases of Hadoop
from trunk despite active development of the mainline. Tom White is
working to cut a new release, but given its record in the last year,
Hadoop's current release process is in need of justification and/or

As Owen suggested earlier, Apache HTTP Server project rules have some
compelling features. In particular, the Release Manager seems like a
useful role. If Hadoop adopted these rules, it could enable more
experimentation in alpha, more frequent releases, and it could still
deliver stable versions. That said, moving from our current model
immediately to odd/even releases, concurrent releases of minor
versions, expressing stability/confidence in versioning, etc. would be
a dramatic and likely disruptive shift. Even discussion on adopting
these rules would unnecessarily delay the next release.

For now, I'd like to propose we adopt only the Release Manager (RM)
role described here:


with the following procedures and caveats:

0) The RM for the next release is confirmed by majority approval of
the PMC (at least 3 +1 votes, more +1 than -1 votes).
1) The RM may be replaced by majority approval of the PMC. Similarly,
if one wants to cut a release from trunk before the next, scheduled
release manager does, a single vote may appoint an intermediate RM
(e.g. a vote could add a RM for a new minor release between releases
run by Tom and Owen)
2) Until the projects can be released separately, one must have commit
privileges on Common, HDFS, and MapReduce to be a RM
3) As in the httpd model, the RM decides how to manage the next
release ({date,feature}-based branching, patches included or elided,
etc.). However:
3.i) All bug fixes/features/etc. in the release must also be in trunk
3.ii) Only blocker bugs, documentation, etc. should be fixed in a patch release
3.iii) Exceptions to (3.ii) are passed per majority consensus by the
committers of the affected projects
4) The product of this process will still become an official release
by majority approval in the PMC

(3.*) and (4) should be familiar.

In the short to medium term, all releases would come off of trunk. If
a self-nominated RM for 0.x does not release before 0.y is ready, then
0.y is released as 0.x, the 0.x branch is retired, and the RM for 0.x
needs to be reelected to release 0.z (where x < y < z). Does this make

If possible, I would like to avoid related, contentious issues on
feature branching and versioning and restrict this discussion to
whether adopting this role would be useful to producing more frequent
Hadoop releases. Tom has volunteered to be the RM for 0.21 and Owen
has volunteered for 0.22; each would be confirmed in a vote apart from
the vote adopting this modification, which will open once this thread
appears to reach consensus. -C

View raw message