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 >> [VOTE] - Release 2.0.5-beta


Copy link to this message
-
Re: [VOTE] - Release 2.0.5-beta
The "release plan" vote is not binding in any way. Nobody "lost" a
vote, or risks having an outcome reversed, because there are no
consequences to these exercises.

Konstantin, I've been trying to tell you for more than a week that you
can go forward without anyone's blessing or consent. There are no
precedents, because the "release plan" vote has been a formality until
now, and I don't know of any other projects that even bother with it.
Most of our committers and PMC members didn't even know who was
eligible to vote on it, because we usually ignore it. What *does*
matter is the majority vote of the PMC on the release artifact. While
we under-defined what the release plan means, we have zero ambiguity
on when a release artifact becomes real.

In the discussion, you were offered a minor release series, help
selecting patches from branch-2, and every administrative barrier was
removed from your path. Instead of taking this and running with it,
you continued to press for... I don't know what. Please decide how
you're going to move a development branch- any of them- forward and
start working on it. There is nothing to "win" in these threads.

This has exposed a bug in our bylaws, which we can fix.

Right now, these "votes" are confusing everybody and stalling the
project. I don't care who comes up with 2.0.5-beta, whether it's part
of 2.1, or if we create 3.0. Any committer who wants to offer an
candidate needs to demonstrate that they have a non-trivial,
non-sectarian proportion of the community behind it by (1) creating
the artifact (2) passing a PMC vote to make that artifact a release.
It's that simple.

With respect to the board: they are not parents, and we are not
children. Neither are they interested or equipped to tell us how to
partition releases of Hadoop. This is routine development, we are
failing at it, but we will recover by eliminating this pointless
ritual and getting back to producing software. -C

On Fri, May 17, 2013 at 1:10 PM, Konstantin Shvachko
<[EMAIL PROTECTED]> wrote:
> BCC: general@
>
> Since we recognize now that this is a vote to overrule previous decision,
> I am referring to Vinod's note on general
> *http://s.apache.org/h7x*
> should this be brought to the attention of the Board?
>
> I don't remember any precedents of this kind in Hadoop history.
> But other projects may have had such experience.
> A clarification on categorizing this action and on voting practices
> from ASF may help.
>
> Thanks,
> --Konstantin
>
>
>
> On Wed, May 15, 2013 at 3:36 PM, Konstantin Shvachko
> <[EMAIL PROTECTED]>wrote:
>
>> Arun,
>>
>> I am glad I at least convinced you to finally announce your release plan
>> and put it into vote.
>> Even though it is to overrule the vote that just completed, which you were
>> against and lost, well - Twice.
>>
>> I am glad you removed the NFS feature from the list proposed earlier.
>>
>> I think this vote is late. The lazy consensus on that issue has been just
>> reached.
>> I don't see the basis for the new vote,
>> and it is not clear what action you seek to approve.
>>
>> Thanks,
>> --Konstantin
>>
>>
>>
>> On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy <[EMAIL PROTECTED]>wrote:
>>
>>> Folks,
>>>
>>> A considerable number of people have expressed confusion regarding the
>>> recent vote on 2.0.5, beta status etc. given lack of specifics, the voting
>>> itself (validity of the vote itself, whose votes are binding) etc.
>>>
>>> IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current
>>> stability of 3 features under debate etc.) have been lost in the discussion
>>> in favor of non-technical (almost dramatic) nuances such as "seizing the
>>> moment". There is now dangerous talk of tolerating incompatibility b/w 2.0
>>> and 2.1) - this is a red flag for me; particularly when there are just 3
>>> features being debated and active committers and contributors are confident
>>> of and ready to stand by their work. All patches, I believe, are ready to
>>> be merged in the the next few days per discussions on jira. This will,
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