hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers" <...@cloudera.com>
Subject Re: HDFS-1623 branching strategy
Date Sun, 10 Jul 2011 04:37:13 GMT
Hi Jakob,

My apologies for taking so long to get back to you - I've been traveling the
last few days.

On Fri, Jul 8, 2011 at 3:40 PM, Jakob Homan <jghoman@gmail.com> wrote:

> 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 seems like a good suggestion to me. The proposal I put forth is not at
all intended to diminish the quantity or quality of reviews, but rather to
make sure that the actual coding (commits to the branch, maintenance of the
branch, and collaboration on the branch) can progress without being stalled
waiting on reviews for each patch. The more reviewers the better, in my

I would only ask that when the announcement is made that this branch is
ready for merge into trunk that those who intend to review it do so as
promptly as possible, and perhaps even announce their intention to do so, so
we can know who to wait on for reviews.

Do we need to vote on this change of policy?

> Finally, the private meeting that led to these discussions was
> unfortunate, exclusionary and against the Apache Way.

You're right - an invitation to the meeting should have been announced. That
said, I can assure you that there was nothing nefarious about this meeting.
Rather, the group of contributors who had previously expressed interest in
implementing NN HA met to review the proposal that was posted on HDFS-1623
to make sure everyone was on the same page with respect to the design.
Regardless of the innocence of this meeting, it still should have been
announced publicly.

> Do we really need another one to work this out?
I don't yet know what concerns Suresh has, but I'd be surprised if they
couldn't be worked out on the mailing lists.

Aaron T. Myers
Software Engineer, Cloudera

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message