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 >
