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