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 must 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