I'd prefer to still keep "Review then Commit" but I'd be interested in lowering the review bar for it as long as the branch gets a solid final review before merge. I don't think a feature branch needs to be micromanaged, but people should still take a quick glance at the commits that come through. My stance on this may change if we find feature commits stagnating for periods of time.
Basically, what I'd be looking for out of a feature branch is something that's: * Implementing a feature too large or with too much experimentation for a single PR. * Is at least looked at semi-regularly to have the opportunity for the community to point out issues or scalability concerns without minor concerns being blockers to progress. Otherwise, it's no different from a giant PR that doesn't get examined until the PR is made. * Reviews should only very rarely be blockers to progress continuing along the branch. The branch shouldn't grind to a halt periodically or even significantly slow progress to cleanup syntax or similar things. The tradeoff for this is I'd expect refactoring in a lot of cases before it hits master to catch up on any of these things that we do care about, but that aren't as important while the branch gets built up initially. * Kept reasonably up to date with master. I really don't want a feature branch sitting out for three months without being synced and then suddenly everything explodes when we try to bring it back. It just causes all sorts of review and testing issues. * Ideally managed so that squashing multiple people's commits appropriately is not a horrible nightmare. * (Hopefully) able to be merged into master more smoothly as it's gotten the major concerns cleaned out along the way. Ideally, we also use this sort of framework to avoid some of the large PRs we've seen around different features that felt very hard to get a grasp of and review. I'm pretty ambivalent on branch committers, and I'd be curious to get some opinions (or possibly experiences if anyone has some) before I form a solid opinion. On Mon, Apr 24, 2017 at 12:01 PM, Michael Miklavcic < michael.miklav...@gmail.com> wrote: > "Branch committers ... do not cast binding votes or vetoes in the project." > It sounds similar to what we do for other PRs except in this case it's 1..n > contributors instead of just one. The step for getting the feature branch > merged into trunk sounds reasonable and clear enough, but as Casey > mentioned I'm also curious what the commit/review lifecycle looks like > while the feature branch is active. > > On Fri, Apr 21, 2017 at 4:00 PM, Casey Stella <ceste...@gmail.com> wrote: > > > So, what would that look like from a practical perspective? > > * I presume commits would still associate to a JIRA, right? > > * Are you proposing changing the strategy from Review then Commit to > Commit > > then Review for these branches? > > > > I know that we have some people who are active in the Hadoop project on > the > > PMC as mentors or are in more established projects with this kind of > thing, > > can you guys chime in about how that looks like and make some suggestions > > as to some gotchas? > > > > Casey > > > > On Fri, Apr 21, 2017 at 5:19 PM, James Sirota <jsir...@apache.org> > wrote: > > > > > Looking at Hadoop's bylaws > > > > > > https://hadoop.apache.org/bylaws.html > > > > > > They have this: > > > > > > Significant, pervasive features are often developed in a speculative > > > branch of the repository. The PMC may grant commit rights on the branch > > to > > > its consistent contributors, while the initiative is active. Branch > > > committers are responsible for shepherding their feature into an active > > > release and do not cast binding votes or vetoes in the project. > > > > > > I would like to have something similar in our bylaws where we can have > > > feature branches with their own set of committers. We may have > > > prototype-grade features that need to be rapidly evolved with the > > feedback > > > from the community. So we would need a lighter process to evolve these > > > features rapidly, while still keeping the community involved. A more > > > rigorous review process can then be applied when the feature is more > > mature > > > and is ready to be committed into master. > > > > > > What do you think? > > > > > > ------------------- > > > Thank you, > > > > > > James Sirota > > > PPMC- Apache Metron (Incubating) > > > jsirota AT apache DOT org > > > > > >
