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
