The concrete example where this would be used is the Alerts UI branch that Raghu is currently working on: https://github.com/iraghumitra/metron-alerts
It would require a lot of feedback from the community and would need to iterate rapidly. Branch review in this sense would mean that people take a top-level glance at the UI and provide feedback. A more formal review would happen prior to the branch being merged back into master. Thanks, James 24.04.2017, 09:17, "Justin Leet" <[email protected]>: > 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 < > [email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 >> > > >> > ------------------- Thank you, James Sirota PPMC- Apache Metron (Incubating) jsirota AT apache DOT org
