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?

-Jakob


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
>

Mime
View raw message