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