Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> [VOTE] Release plan for Hadoop 2.0.5

Copy link to this message
Re: [VOTE] Release plan for Hadoop 2.0.5
Hi Chris and Arun,

You keep twisting around the purpose of the vote and my position in it.
As I said before: http://s.apache.org/WBf
I am not against the features. And I am not blocking them.
I propose to release them in a different than yours order, addressing
features vs. stability tradeoff.

Arun, you should remember that I started this argument with the proposal to
shift versions.
Just as Andrew proposed in his last email.
But you rejected the idea at the time.
This would have let people who want to work on stable 2.0 series, while you
could have continued releasing 2.1 with more features.

I think the lesson Arun learned from the longevity of branch-1 is wrong.
The lesson I learn is that if you keep one branch for too long you get
others branch off and you start loosing important members of the community
like Facebook. I think we should produce feature releases from trunk and
often. With the stability of a particular branch coming later when there is
a critical mass of contributors to work on its stabilization.

I don't know how to stop votes even if I wanted to.
As Apache members you should have more vote-stopping power than me if you
think it is against ASF norms.

On Sat, May 11, 2013 at 7:03 AM, Arun C Murthy <[EMAIL PROTECTED]> wrote:

> Chris,
>  I couldn't agree more with the sentiments - thank you for expressing them
> in such a lucid manner.
>  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
> <[EMAIL PROTECTED]> 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