hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: [VOTE] Direction for Hadoop development
Date Tue, 07 Dec 2010 01:09:41 GMT
On Dec 6, 2010, at 3:45 PM, Doug Cutting wrote:
> On 12/06/2010 02:40 PM, Chris Douglas wrote:
>> It is nonsense to assert that every PMC member has the right to block
>> work because it conflicts with their personal vision  [ ... ]
> 
> This is the way Apache projects operate.  It requires that folks listen to criticism
and potentially accept compromises if they wish to make progress.  If folks cannot reach consensus
in an area then that area will not make progress.

Generally speaking, vetoing extension interfaces without a compelling
technical reason is not the way Apache operates.  We make extensions
modular so that diverse collaborators can specialize according to
their own needs, not just your needs.

The compelling reason would be a measured performance impact or some
other objective degradation of the existing product that can be
evaluated by others as a cost/benefit tradeoff and perhaps compensated
by modifying the implementation.

>> 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.
> 
> I am interested in having this project primarily deliver a reliable, efficient MapReduce
kernel implementation.  That's the core functionality that folks seek to not recreate.  The
project should focus on a minimal, low-level MapReduce API for this kernel and permit other
projects to build higher-level abstractions.

That is something people can vote on.  Changes to the existing products,
including plans like the one Owen described, are subject to vote if anyone
disagrees with them.  They are also subject to veto if and only if they
are to be applied to the current release branch (or a released branch).

If a PMC member insists on making design opinion the sole basis of their
vetoes, then they are not collaborating with the rest of the PMC.  The
board will recommend that such a person be removed from the PMC so that
the majority can continue to develop the product in peace.  If there is
enough interest in a parallel line of development, then the board will
recommend splitting the PMC into two or more projects that can compete
on the merits of their own designs, with the existing product name
remaining with the majority.  Both recommendations are based on our
experience with Tomcat (which quickly solved the disagreement on its
own, once the choices were laid out, by allowing divergent designs on
separate major versions of the same product).

....Roy


Mime
View raw message