Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Hadoop >> mail # general >> [DISCUSS] change bylaws to add "branch committers"


+
Chris Douglas 2013-07-15, 23:10
+
Luke Lu 2013-07-16, 18:31
+
Tsuyoshi OZAWA 2013-07-17, 03:52
+
Chris Nauroth 2013-07-17, 17:31
+
Eli Collins 2013-07-17, 17:43
+
Robert Evans 2013-07-18, 16:31
Copy link to this message
-
Re: [DISCUSS] change bylaws to add "branch committers"
When would a branch committer privilege terminate?

-Kihwal

On 7/18/13 11:31 AM, "Robert Evans" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>>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
>
+
Chris Douglas 2013-07-23, 05:28