Draft Guidelines for Committing Code Reviews
The following guidelines shall be followed when committing code reviews.
Self-commits are not allowed
Code reviews are expected to take place within the next 1.5 working days after the code has been submitted to Gerrit
All Commits must be reviewed and integration tested.
Depending on the project state, there is a variable depending on the % of committers to perform code review
Feedback provided by voting "-1" (issue), "0" (ok, neutral, abstain), "+1" (approve)
Incubation: “+1” from 30% of committers (min: 2); no “-1”
Mature: “+1” from 60% of committers; no “-1”
Core: “+1” from 75% of committers; no “-1”
The code should not be accepted if there are open issues, but should as soon as the minimum threshold of reviews have come in.
Code may never be committed if there are outstanding -1s on a review
The issue identified in the -1 review must be fixed or
The reviewer who posted a -1 must agree to change their review score following a clarification discussion or
Two committers agree to override the -1 review
The PTL and all committers must be added to all code reviews so that they are aware of changes. PTLs should ensure that missing committers are added to reviews.
If the code change is to fix a bug, the author of the bug report
Must be added to the reviewer list and
Must +1 the change or in the event of the bug author being unavailable
Two committers agree the bug has been satisfactorily addressed
When the code change is coming from a certain organization (for example a company or group developing a feature as a team) the review
Must be reviewed and +1'd by at least two reviewers outside that group
Must be committed and merged by a committer outside that group