Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> Re: [VOTE] Release candidate 0.20.203.0-rc0


Copy link to this message
-
Re: [VOTE] Release candidate 0.20.203.0-rc0
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB