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

To clarify, is there any restriction on who may give the +1s? For example,
if a branch has a group of 5 committers primarily authoring the patches, can
the three +1s be made by a subset of those committers?

-Todd

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
>

--
Todd Lipcon
Software Engineer, Cloudera

That's certainly not the intention, although I note that the current
+1 requirement on code changes would apparently allow a committer to
+1 h{is,er} own patch:
"A change made to a codebase of the project and committed by a
committer. This includes source code, documentation, website content,
etc. Lazy consensus of active committers, but with a minimum of one
+1. The code can be committed after the first +1."

On Mon, Jul 11, 2011 at 5:17 PM, Todd Lipcon <[EMAIL PROTECTED]> wrote:
> To clarify, is there any restriction on who may give the +1s? For example,
> if a branch has a group of 5 committers primarily authoring the patches, can
> the three +1s be made by a subset of those committers?
>
> -Todd
>
> 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
>>
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

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

+1 to Eli's wording.

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

+1 from me as well.

Thanks for running this vote, Jakob.

Aaron

On Jul 11, 2011, at 7:44 PM, Jakob Homan <[EMAIL PROTECTED]> wrote:

> +1 to Eli's wording.
>
> 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
>>>
>>

+1

On Tue, Jul 12, 2011 at 12:56 AM, Aaron T. Myers <[EMAIL PROTECTED]> wrote:

> +1 from me as well.
>
> Thanks for running this vote, Jakob.
>
> Aaron
>
> On Jul 11, 2011, at 7:44 PM, Jakob Homan <[EMAIL PROTECTED]> wrote:
>
> > +1 to Eli's wording.
> >
> > 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
> >>>
> >>
>

--
Connect to me at http://www.facebook.com/dhruba

On 07/11/2011 05:41 PM, Eli Collins wrote:
> 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>

+1

Doug

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

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

+1

Cheers,
Nige
On Jul 12, 2011, at 10:01 AM, Stack <[EMAIL PROTECTED]> wrote:

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

+1

Arun

On Jul 11, 2011, at 5:11 PM, Jakob Homan 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

+1

mahadev

On Mon, Jul 11, 2011 at 9:26 PM, Arun C Murthy <[EMAIL PROTECTED]> wrote:
> +1
>
> Arun
>
> On Jul 11, 2011, at 5:11 PM, Jakob Homan 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
>
>

Sounds fine to me. +1

On Mon, Jul 11, 2011 at 9:30 PM, Mahadev Konar <[EMAIL PROTECTED]>wrote:

> +1
>
> mahadev
>
> On Mon, Jul 11, 2011 at 9:26 PM, Arun C Murthy <[EMAIL PROTECTED]>
> wrote:
> > +1
> >
> > Arun
> >
> > On Jul 11, 2011, at 5:11 PM, Jakob Homan 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
> >
> >
>

--
Todd Lipcon
Software Engineer, Cloudera

+1 from me.

+1

Tom

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
>

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.

+1

With 13 +1's from PMC members, the vote passes.  I'll update the
language and commit it to the documentation.
-jg
On Fri, Jul 15, 2011 at 9:18 AM, Owen O'Malley <[EMAIL PROTECTED]> wrote:
>
> 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.
>
> +1
>
>