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

Switch to Threaded View
Hadoop >> mail # general >> [VOTE] Direction for Hadoop development


Copy link to this message
-
Re: [VOTE] Direction for Hadoop development
On Mon, Dec 6, 2010 at 11:30 AM, Doug Cutting <[EMAIL PROTECTED]> wrote:
> On 12/01/2010 07:40 AM, Owen O'Malley wrote:
>>>
>>> This is unfortunately not the way Apache projects operate. Vetos are
>>> not overridden by a majority votes.
>>
>> This isn't overriding the veto. You've based your veto on changes in
>> project plan that have never been discussed or agreed to.
>
> Apache projects don't have project plans that are created by majority votes.

This reasoning is exactly opposite the facts at issue.

The veto of HADOOP-6685 was based, in part, on a component that the
patch proposed to modify. Due to an individual's project plan- one
that "does not support" extending that component- that change was not
allowed to go forward.

Asserting that the PMC does not create project plans by majority vote
is correct in some ways; the PMC does not plan out every feature and
pre-approve all work contributed in a release. This does not require
that its members remain collectively mute on the project's direction.
It is nonsense to assert that every PMC member has the right to block
work because it conflicts with their personal vision for Hadoop. That
doesn't scale. Instead, it makes authority so ambiguous and diffuse
that project direction defaults to the agenda of bullies.

This has been turned on its head. The procedural question is whether
individual votes establish project plans, not majority votes.

To avoid a pedantic, lawyerly debate on whether this aspect of the
veto was valid, its premise was raised as an issue for the community,
so it could reach consensus and define the scope of its project. This
approach was supposed to incite more constructive debate on an obvious
difference in how participants see Hadoop development over the long
term. So do you want to have that discussion, or do you want to bicker
about whether you'll be forced to accept the result? -C

On the vote: I'm +1 on supporting library/platform code in the Hadoop
project, particularly in MapReduce. Reducing MR to a distributed sort
implementation is not a direction I'm interested in.