hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arun C Murthy <...@hortonworks.com>
Subject Re: [VOTE] Release plan for Hadoop 2.0.5
Date Sat, 11 May 2013 14:03:00 GMT

 I couldn't agree more with the sentiments - thank you for expressing them in such a lucid

 There is one nit I'd like to point out though:

On May 10, 2013, at 1:34 PM, Chris Douglas wrote:

> On Thu, May 9, 2013 at 11:14 PM, Konstantin Shvachko
> <shv.hadoop@gmail.com> wrote:
>> Not everybody who is voting now provided context in the discussion thread.
>> You did. And I am sorry I did not understand it.
> I'll try to be clearer.
> It's unnecessary for you to ask permission to roll a release
> containing (or omitting) the features you want. This vote is redundant
> with the release vote; it's an unnecessary formalism in our bylaws. If
> you want to release 2.0.5 with the features you want and assemble
> other community members to help stabilize it in a 2.0.x series...
> great. Do that.

This is the nit.

In the ASF, the RM *does not* have the power to choose bits and pieces of code from SVN. He
can remove bits from SVN - only by veto'ing the changes.

Roy was very clear on this on this very list: http://s.apache.org/Gt9

I'll quote directly from him -

>> The only thing the RM has authority over is the building of a source
>> package, based on the contents of our subversion, that can then be
>> put up for vote.  They can decide what snapshot to tag for a build.
>> They can decide not to build anything at all.  They can also do all sorts
>> of organizational support, advocacy, pleading, or whatever in order to
>> encourage the rest of the project committers to apply changes, vote
>> for things under issue, etc.
>> They do not have the right to pick and select whatever variation
>> of the product they might like to build, short of vetoing (with a
>> valid reason) any changes that they as a PMC member believe do not
>> belong on the branch. Likewise, the RM cannot include in the build
>> any change that has been vetoed by others, and their build cannot
>> be released if it contains any such changes that have been vetoed
>> since it was built.  The RM has the right to kill their own build
>> if they learn something during the release process that they think,
>> for whatever reason, causes the build to be unreleasable.  

Furthermore, this vote is, essentially, against the rules on the ASF since it's trying to
block changes into a specific branch (i.e. branch-2).

Again, quoting Roy from the same email:

>> Any committer can commit wherever they have been given permission
>> to commit by the PMC.  Generally, they do so collaboratively.
>> I've never encountered a situation in my own projects which developers
>> were committing at cross-purposes, even when they disagree on content,
>> though I've seen commit wars elsewhere.  We'd expect the PMC
>> to step in if they did.


In all, Konstantin - can you please stop this vote? 

As I have repeatedly pleaded with you - please work with developers working on the issues
you seem set against (HDFS-347, Snapshots, Windows support) and come to a *consensus*. That
is the only way to reach the goals you desire. 

You are welcome to veto/revert any of the changes from all of Apache Hadoop subversion with
a valid technical reason.

>  Again, we don't- we can't- assign work by voting. This is a poll, and a feckless one.

I'll repeat, this vote doesn't make any sense (regardless of the artistic words in our bylaws
which need to change/go). This is more of a populistic poll which tries to sway people with
horror stories of instability, non-convergence of hadoop-2 to a stable state etc. etc.

IAC, this vote is against the norms of the ASF, please end this.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message