hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Homan <jgho...@gmail.com>
Subject Re: HDFS-1623 branching strategy
Date Fri, 08 Jul 2011 22:40:47 GMT
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?


On Fri, Jul 8, 2011 at 3:17 PM, Doug Cutting <cutting@apache.org> 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

View raw message