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.
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.
> 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]>
> >> 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