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
