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 Threaded View
Hadoop >> mail # general >> [VOTE] Change bylaws to require 3 binding +1s for branch merge


Copy link to this message
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge
+1.

Tsz-Wo

________________________________
From: Stack <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Tuesday, July 12, 2011 10:01 AM
Subject: Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge

+1

On Mon, Jul 11, 2011 at 5:41 PM, Eli Collins <[EMAIL PROTECTED]> wrote:
> +1   Sounds good to me.
>
> Something like the following?
>
> Index: main/author/src/documentation/content/xdocs/bylaws.xml
> =================================================================>             <p>Lazy consensus of active committers, but with a minimum of
> -            one +1. The code can be committed after the first +1.</p></li>
> +            one +1. The code can be committed after the first +1, unless
> +            the code change represents a merge from a branch, in which case
> +            three +1s are required.</p></li>
>
>
>
>
> On Mon, Jul 11, 2011 at 5:11 PM, Jakob Homan <[EMAIL PROTECTED]> wrote:
>> As discussed in the recent thread on HDFS-1623 branching models, I'd
>> like to amend the bylaws to provide that branches should get a minimum
>> of three committer +1s before being merged to trunk.
>>
>> The rationale:
>> Feature branches are often created in order that developers can
>> iterate quickly without the review then commit requirements of trunk.
>> Branches' commit requirements are determined by the branch maintainer
>> and in this situation are often set up as commit-then-review.  As
>> such, there is no way to guarantee that the entire changeset offered
>> for trunk merge has had a second pair of eyes on it.  Therefore, it is
>> prudent to give that final merge heightened scrutiny, particularly
>> since these branches often extensively affect critical parts of the
>> system.  Requiring three binding +1s does not slow down the branch
>> development process, but does provide a better chance of catching bugs
>> before they make their way to trunk.
>>
>> Specifically, under the Actions subsection, this vote would add a new
>> bullet item:
>> * Branch merge: A feature branch that does not require the same
>> criteria for code to be committed to trunk will require three binding
>> +1s before being merged into trunk.
>>
>> The last bylaw change required lazy majority of PMC and ran for 7
>> days, which I believe would apply to this one as well.  That would
>> have this vote ending 5pm PST July 18.
>> -Jakob
>>
>
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