Jakob Homan
2011-07-12, 00:11
Todd Lipcon
2011-07-12, 00:17
Jakob Homan
2011-07-12, 00:27
Eli Collins
2011-07-12, 00:41
Jakob Homan
2011-07-12, 00:44
Aaron T. Myers
2011-07-12, 00:56
Dhruba Borthakur
2011-07-12, 04:22
Doug Cutting
2011-07-12, 16:47
Stack
2011-07-12, 17:01
Tsz Wo Sze
2011-07-13, 07:26
Nigel Daley
2011-07-13, 21:09
Arun C Murthy
2011-07-12, 04:26
Mahadev Konar
2011-07-12, 04:30
Todd Lipcon
2011-07-12, 04:38
Suresh Srinivas
2011-07-12, 04:44
Tom White
2011-07-13, 21:36
Owen O'Malley
2011-07-15, 16:18
Jakob Homan
2011-07-22, 20:26
-
[VOTE] Change bylaws to require 3 binding +1s for branch mergeJakob Homan 2011-07-12, 00:11
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
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
+
Jakob Homan 2011-07-12, 00:11
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeTodd Lipcon 2011-07-12, 00:17
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
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
+
Todd Lipcon 2011-07-12, 00:17
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeJakob Homan 2011-07-12, 00:27
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 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
>
+
Jakob Homan 2011-07-12, 00:27
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeEli Collins 2011-07-12, 00:41
+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
>
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
>
+
Eli Collins 2011-07-12, 00:41
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeJakob Homan 2011-07-12, 00:44
+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
>>
>
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
>>
>
+
Jakob Homan 2011-07-12, 00:44
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeAaron T. Myers 2011-07-12, 00:56
+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
>>>
>>
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
>>>
>>
+
Aaron T. Myers 2011-07-12, 00:56
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeDhruba Borthakur 2011-07-12, 04:22
+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 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
+
Dhruba Borthakur 2011-07-12, 04:22
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeDoug Cutting 2011-07-12, 16:47
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
> 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
+
Doug Cutting 2011-07-12, 16:47
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeStack 2011-07-12, 17:01
+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
>>
>
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
>>
>
+
Stack 2011-07-12, 17:01
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeTsz Wo Sze 2011-07-13, 07:26
+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
>>
>
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
>>
>
+
Tsz Wo Sze 2011-07-13, 07:26
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeNigel Daley 2011-07-13, 21:09
+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
>>>
>>
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
>>>
>>
+
Nigel Daley 2011-07-13, 21:09
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeArun C Murthy 2011-07-12, 04:26
+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
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
+
Arun C Murthy 2011-07-12, 04:26
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeMahadev Konar 2011-07-12, 04:30
+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
>
>
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
>
>
+
Mahadev Konar 2011-07-12, 04:30
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeTodd Lipcon 2011-07-12, 04:38
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
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
+
Todd Lipcon 2011-07-12, 04:38
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeSuresh Srinivas 2011-07-12, 04:44
+1 from me.
+
Suresh Srinivas 2011-07-12, 04:44
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeTom White 2011-07-13, 21:36
+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
>
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
>
+
Tom White 2011-07-13, 21:36
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeOwen O'Malley 2011-07-15, 16:18
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
+
Owen O'Malley 2011-07-15, 16:18
-
Re: [VOTE] Change bylaws to require 3 binding +1s for branch mergeJakob Homan 2011-07-22, 20:26
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
>
>
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
>
>
+
Jakob Homan 2011-07-22, 20:26
