hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: [VOTE] Direction for Hadoop development
Date Tue, 07 Dec 2010 17:18:32 GMT
On 12/06/2010 05:09 PM, Roy T. Fielding wrote:
> 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.

Roy, thanks for your thoughts here.

I have not intended to veto an extension mechanism.  In this case, we 
already have an extension mechanism.  The proposal is to change the 
extension mechanism incompatibly with unclear benefits, add 
implementations of several extensions to the kernel, and incompatibly 
change a widely-used file format.  In general I support improving 
extension mechanisms, but oppose gratuitous changes to file formats and 
the inclusion of new user-level functionality in the kernel.  I'd like 
the issue to focus solely on the extension mechanism to clarify the 
discussion, not on adding extensions to the kernel or file formats.

Tom long ago provided patches showing how the existing configuration 
system can provide equivalent extension implementations outside of the 
kernel with no incompatible changes.  (MAPREDUCE-376 and MAPREDUCE-377)

> Changes to the existing products,
> including plans like the one Owen described, are subject to vote if anyone
> disagrees with them.

Is this described somewhere?  The HTTPD page says, "Long term plans are 
simply announcements that group members are working on particular issues 
related to the Apache software. These are not voted on [...]."

> They are also subject to veto if and only if they
> are to be applied to the current release branch (or a released branch).

Owen intends to merge this patch to a release branch.

> 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.

Files written by the proposed new version would not be readable by older 
versions of Hadoop.  An unaltered application that upgrades to the newer 
version would begin creating files that could not be interchanged with 
folks running the older version.

> 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.

I am not the sole PMC member to express these opinions.


View raw message