One question that we need to discuss is whether every merge is RTC (Review-than-Commit) or CTR (Commit-than-Review).
My take is that we should start with RTC and, if the review process gets in the way of innovation, then we go to CTR. But, until everyone learns the rules of the road, I think RTC is justified. Under RTC rules, all commits should be reviewed (+1) by three committers before being merged. (If you are a committer, then two others are needed.). Any committer can veto (-1) a patch - which should cause a discussion about resolving the veto. So, #1 - your suggestion sounds right with the need for three committers to approve before merge to develop. For #2, I think it should be a separate branch and require 3 signoffs for now. As the project matures, "obvious" commits can be CTR. My $.02. -- justin On May 7, 2015 5:44 AM, "Pid" <[email protected]> wrote: > Hi, > > > Like it says, can we discuss how the review process will work? > For these examples: > > > 1. I would like to work on upgrading the Spring dependencies in gfsh. > > Proposed approach: file a JIRA, cut a feature branch, push it & then what? > > > 2. I would like to add an entry to .gitignore (.idea/) > > Does this require a JIRA, a feature branch and a review? > > > > p > > -- > > [key:62590808] >
