hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: [DISCUSSION] Adopt the Release Manager role for Hadoop
Date Wed, 05 May 2010 19:01:04 GMT
> 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 was following the sequence Doug suggested in the last thread on the
release process. I can draft a vote if no discussion of this is
necessary.

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

Sorry, I meant minor releases. I assumed patch releases per (3.ii) and
(3.iii). The rules seem to allow an RM to cut releases from branches
as well as trunk, so I was trying to avoid the confusing prospect of
releasing, for example, 0.22 from the 0.21 branch instead of from
trunk (unless the odd/even release convention were adopted).

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

I meant to describe what's happening with 0.21, more or less. Given
requirement (3.i), nothing should be in (unreleased) 0.x that isn't
also in trunk. If 0.x has a complex/buggy feature that's preventing it
from being released, allowing someone to RM a release without it and
call that 0.x, pushing the feature to 0.y is messy, but not as
confusing (given Hadoop's deprecation and interface stability
guarantees). It's also a merciful way to kill a stuck release without
indicting the struggling RM. -C

Mime
View raw message