hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: [DISCUSS] What is the purpose of merge vote threads?
Date Thu, 24 Oct 2013 22:46:28 GMT
On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth <cnauroth@hortonworks.com> wrote:
> When the voting happens on jira with a finalized merge patch, I know
> exactly what I'm voting for, because it's the same review-and-commit
> process that we follow every day with the extra requirement of 3 +1s.  When
> it happens on email, it's less clear to me exactly what I'm voting for.

Here's my take, FWIW.  The entire project needs to determine whether
it is willing to take on the maintenance of code developed in a
branch.  This vote needs the widest audience.  On the other hand,
discussion on the umbrella Jira for the branch concerns the precise
details of the merge commit.  Even if the project is generally willing
to accept maintenance of the code in a branch, committing it should
not break the build that day.  So fine-tuning the precise details of
the merge often happens in Jira rather than as a part of the formal
merge vote.  Sometimes these are determined in parallel.

Since a -1 must always be accompanied by a rationale, it should be
clear whether such a vote concerns a fine point of the specific patch
that's easily corrected or whether it's about a fundamental problem
with the branch that will take longer to address.  Either sort might
be cast in either place.  A fine-point objection shouldn't reset
voting clocks and a fundamental objection concerns things that cannot
be fixed in a voting window.  If something lies in the middle then
should be discussion until consensus is reached about whether the
merge date need be delayed, voting restarted later, etc.  I don't see
a need for a more rigid policy here since we haven't seen things
running amok around branch merges due to a lack of policy.

Is that consistent with other folks understanding?


View raw message