I also have concerns. While those working on the 1073 branch haven't abused the commit-then-review process, the fact remains that the final merge to trunk is equivalent to a 1.3MB patch that makes far-reaching changes to the guts of the NN. Asking the reviewers most experienced in this code to do such a herculean review such a merge is an unreasonable request. So (again with no malice on anyone's part), we've ended up with a huge, far-reaching changeset that was committed under a liberal policy that's not accepted on trunk being merged into trunk based on a single +1 (per the bylaws as I read them, it's not necessary to have more than that to merge a branch to trunk). This is not a good situation.
The tweak I would make to the suggested process is to require that the final trunk merge have a higher threshold to commit. Three +1s from committers would be my suggestion. This would also be an area where cross-organization reviews would help significantly, but there's nothing in the ASF to mandate such a requirement. Finally, the private meeting that led to these discussions was unfortunate, exclusionary and against the Apache Way. Do we really need another one to work this out? -Jakob On Fri, Jul 8, 2011 at 3:17 PM, Doug Cutting <[email protected]> wrote: > On 07/08/2011 12:22 PM, Suresh Srinivas wrote: >> This is a critical feature for HDFS. This proposal is not exactly >> what I had envisioned. Why don’t we meet again to discuss and come up >> with a proposal for branching and development-process? > > Suresh, > > What are your concerns with this proposal? > > Thanks, > > Doug >
