Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Hadoop >> mail # dev >> Re: [DISCUSS] What is the purpose of merge vote threads?


+
Tsz Wo \ 2013-10-25, 01:19
+
Suresh Srinivas 2013-10-25, 16:35
+
Doug Cutting 2013-10-25, 17:18
+
Vinod Kumar Vavilapalli 2013-10-25, 17:56
+
Doug Cutting 2013-10-25, 19:04
+
Chris Nauroth 2013-11-07, 17:53
+
Chris Nauroth 2013-10-24, 20:40
+
Aaron T. Myers 2013-10-24, 21:07
+
Chris Nauroth 2013-10-24, 21:51
Copy link to this message
-
Re: [DISCUSS] What is the purpose of merge vote threads?
On Thu, Oct 24, 2013 at 2:51 PM, Chris Nauroth <[EMAIL PROTECTED]> 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?

Doug
+
Aaron T. Myers 2013-10-25, 06:51