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
Doug Cutting 2013-10-24, 22:46
Copy link to this message
Re: [DISCUSS] What is the purpose of merge vote threads?
On Thu, Oct 24, 2013 at 3:46 PM, Doug Cutting <[EMAIL PROTECTED]> wrote:

> 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?

+1, I agree with all of this, and this is how I've always understood the
merge vote process myself.