+1 This sounds like an effective way to get more people involved and get people involved more deeply. As a practical matter, I think at least one full committer or PMC member should stay active in the feature branch to provide guidance. I expect this will help ease some of the challenges with big merges when it comes time for the feature branch to merge back to trunk.
Chris Nauroth Hortonworks http://hortonworks.com/ On Tue, Jul 16, 2013 at 8:52 PM, Tsuyoshi OZAWA <[email protected]>wrote: > I agree with your proposal. If code tracking gets easier, it can > reduce the reviewer's time and effort. > +1(non-binding). > > On Wed, Jul 17, 2013 at 3:31 AM, Luke Lu <[email protected]> wrote: > > Sounds good to me. This would encourage non-trivial code contribution and > > maintenance. > > > > +1. > > > > Are we going to enforce branch ACLs (mostly to prevent mistakes)? > > > > > > > > > > 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 > >> > > > > -- > - Tsuyoshi >
