Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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.

Best,
Aaron
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB