hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom White <...@cloudera.com>
Subject Re: [DISCUSSION] Adopt the Release Manager role for Hadoop
Date Wed, 05 May 2010 16:45:31 GMT
Hi Chris,

Overall this looks good to me. Thanks for drafting it.

Should we create a document for the website that we vote on? I think
you've captured most of what we need now in this email, but it would
be a good start for the bylaws when we get back to them.

I've included a couple more comments inline below.

Cheers,
Tom

On Tue, May 4, 2010 at 1:31 PM, Chris Douglas <cdouglas@apache.org> wrote:
> 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
> revision.
>
> 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:
>
> http://httpd.apache.org/dev/release.html
>
> 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.

Wouldn't this prohibit a point 0.21 release? Do we want to do this?

> 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
> sense?

I agree with the sentiment, but in practice it might be confusing to
release 0.y as 0.x - I worry about getting JIRA issues marked as being
fixed in 0.x not 0.y, and in general updating all the references to
0.y (including branches). How about just skipping the 0.x version?

>
> 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
>

Mime
View raw message