+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
