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
