hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: [VOTE] Release candidate 0.20.203.0-rc0
Date Mon, 02 May 2011 20:40:47 GMT
On 05/02/2011 01:07 PM, Arun C Murthy wrote:
> # Roy clearly clarified the way forward: http://s.apache.org/tD4 (which
> Owen has since incorporated by breaking into individual patches).

Roy suggested a three ways forward and possible outcomes:

Roy Fielding wrote:
>  a) break the changes down into a sequence of patches, create jira
>     issues for each one (or append to the existing issue), and then
>     provide the group with a list of the issue links so that people
>     can quickly +1 each one.  When it seems worthwhile to you, create
>     a branch off of some prior Apache release point in svn and commit
>     each patch to it until the branch is identical to (or, in your own
>     opinion, better than) the source code that you have tested locally.
>     Then RM a tarball and start a release vote.  Since all of this is
>     being done in jira and svn, others can help you do all but the
>     first part (breaking down the big patch).
> 
> or
> 
>  b) create a branch off of some prior Apache release point in svn
>     and replay the internal Y! commits on that branch until the branch
>     source code is identical to what you have tested locally.  Then
>     RM a tarball based on that branch and start a release vote.
>     Since the history is now in svn, others could do the RM bit if
>     you don't have time.
> 
> or
> 
>  c) create a branch off of some prior Apache release point in svn
>     and apply one big ugly patch to it.  Then RM a tarball based
>     on that branch and ask for a release vote.
> 
> You will note that none of the above requires a discussion on this
> list prior to the release vote, though (a) would likely result in
> more +1s than (b), and (b) would likely receive more +1s than (c).
> Regardless, the release vote is a lazy majority decision.
>
>  [ ... ]
>
> When the release vote happens, encourage folks to test and +1
> the release.  If it passes, woohoo!  If not, then listen to the
> reasons given by the other PMC members and see if you can make
> enough changes to the release to get those extra +1s.

I believe that Owen chose (b).  We're now at the release vote and I am a
PMC member giving reasons for my vote.

Also note that, on the common-dev thread, Eli & Tom have both noted a
number of inconsistencies between this set of patches and trunk, 0.22
and even prior 0.20 branches and releases.  In addition to the lack of
community involvement in patch selection, these issues concern me.

I cannot in good conscience vote for this release as a community product.

Doug

Mime
View raw message