Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
MIME-Version: 1.0
In-Reply-To: <CE12C05C.3FE06%kihwal@yahoo-inc.com>
References: <CE0D8218.16396%evans@yahoo-inc.com>
	<CE12C05C.3FE06%kihwal@yahoo-inc.com>
Date: Mon, 22 Jul 2013 22:28:38 -0700
Message-ID: 
 <CACO5Y4xJXo7LKefzG+t4fyNjFYGa1sFPVvi_sW1yVac0gq8e-g@mail.gmail.com>
Subject: Re: [DISCUSS] change bylaws to add "branch committers"
From: Chris Douglas <cdouglas@apache.org>
To: "general@hadoop.apache.org" <general@hadoop.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jul 16, 2013 at 11:31 AM, Luke Lu <llu@apache.org> wrote:
> Are we going to enforce branch ACLs (mostly to prevent mistakes)?
On Mon, Jul 22, 2013 at 11:47 AM, Kihwal Lee <kihwal@yahoo-inc.com> wrote:
> When would a branch committer privilege terminate?

When the branch merges. If we used branch ACLs, that would be a
consequence, but it's a clear policy, either way. If a branch
contributor stays involved they're usually made into full committers,
so we probably don't need to manage ACLs too tightly.

I also agree with Chris and Eli's qualifications. The intent is to
support development of active features, not create a sandbox that will
never merge back.

I'll call a vote starting tomorrow on the following diff to the
bylaws, unless someone has modifications to the phrasing. -C

Index: main/author/src/documentation/
content/xdocs/bylaws.xml
===================================================================
--- main/author/src/documentation/content/xdocs/bylaws.xml
(revision 1505876)
+++ main/author/src/documentation/content/xdocs/bylaws.xml      (working copy)
@@ -76,6 +76,13 @@
         commit access from the PMC. Such reinstatement is subject to
         consensus approval of active PMC members.</p>

+        <p>Significant, pervasive features are often developed in a speculative
+        branch of the repository. The PMC may grant commit rights on the
+        branch to its consistent contributors, while the initiative is active.
+        Branch committers are responsible for shepherding their feature into
+        an active release and do not cast binding votes or vetoes in the
+        project.</p>
+
         <p>All Apache committers are required to have a signed Contributor
         License Agreement (CLA) on file with the Apache Software
         Foundation. There is a <a
@@ -220,6 +227,9 @@
              Consensus approval requires 3 binding +1 votes
              and no binding vetoes.</li>

+        <li> <strong>Lazy Consensus -</strong>
+             Lazy consensus requires no -1 votes ('silence gives assent').</li>
+
         <li> <strong>Lazy Majority - </strong>
              A lazy majority vote requires 3 binding +1
              votes and more binding +1 votes than -1 votes.</li>
@@ -279,6 +289,12 @@

             <p>Lazy 2/3 majority of PMC members</p></li>

+         <li> <strong>New Branch Committer</strong>
+
+            <p>When a branch committer is proposed for the PMC</p>
+
+            <p>Lazy consensus of active PMC members</p></li>
+
          <li> <strong>New Committer</strong>

             <p>When a new committer is proposed for the project</p>
@@ -291,6 +307,13 @@

             <p>Consensus approval of active PMC members</p></li>

+         <li> <strong>Branch Committer Removal</strong>
+
+            <p>When removal of commit privileges is sought <strong>or</strong>
+               when the branch is merged to the mainline</p>
+
+            <p>Lazy 2/3 majority of active PMC members</p></li>
+
          <li> <strong>Committer Removal</strong>

             <p>When removal of commit privileges is sought.  Note: Such

On Mon, Jul 22, 2013 at 11:47 AM, Kihwal Lee <kihwal@yahoo-inc.com> wrote:
> When would a branch committer privilege terminate?
>
> -Kihwal
>
> On 7/18/13 11:31 AM, "Robert Evans" <evans@yahoo-inc.com> wrote:
>
>>I like the idea too.  My only concern would be the load it would put on
>>INFRA to support this, but I don't see hundreds of new committers showing
>>up so I am +1 on it.
>>
>>--Bobby
>>
>>On 7/17/13 12:43 PM, "Eli Collins" <eli@cloudera.com> wrote:
>>
>>>+1  sounds reasonable to me.  There's an assumption that we won't
>>>release from feature branches, worth saying that explicitly.
>>>
>>>On Mon, Jul 15, 2013 at 4:10 PM, Chris Douglas <cdouglas@apache.org>
>>>wrote:
>>>> In some projects at the ASF, a PMC member can grant commit rights on a
>>>> feature branch to a contributor with minimal overhead. When developing
>>>> significant or pervasive features, collaboration across linked JIRAs
>>>> can be difficult for the contributors to maintain and for reviewers to
>>>> track. Since we already support this model of branched development for
>>>> Hadoop committers, extending it to newer members of the community
>>>> seems pretty natural.
>>>>
>>>> Given that many of the major feature branches in 2.1 included at least
>>>> one significant contributor without a write bit, this pattern is also
>>>> common enough to adjust our bylaws.
>>>>
>>>> In one possible protocol, a PMC member can propose a set of
>>>> contributors for a particular feature branch. If there is no NACK,
>>>> then those people are given a commit bit on the branch. Other
>>>> responsibilities for committers- such as reviewing patches, vetoing
>>>> changes in trunk, etc.- do not apply. The protocol on the branch
>>>> should not require explicit rules, but contributors should keep in
>>>> mind that our bylaws also require 3 +1s to merge the branch back;
>>>> creating a feature branch is not a promise to merge. One would also
>>>> expect proposed branch committers to have already written some code as
>>>> the base of the new branch.
>>>>
>>>> Thoughts? Modifications to the protocol? -C
>>
>