Proposed workflow changes:
- Code review +2 votes will no longer trigger Jenkins.
- Core reviewers may now feel free to vote with any value between -2 and +2 on any change. They should vote +2 if they want their vote to be counted as meeting the inclusion criteria of "positive reviews from at least 2 core developers".
- Core reviewers should periodically scan for reviews that are ready for approval and approve them if they feel they have been sufficiently reviewed and the inclusion criteria are met.
- To approve a change and start the merge process, core reviewers should vote +1 in the "Approved" category (click the review button again, and only change the value for the "Approved" category). [2]
The review list will look like this:
Note the final column labeled "A" for "Approved". Reviewers can scan the list and see that any change with a check in the "A" column has been approved, and is either undergoing testing ("V" is blank), or has failed tests ("V" has a red "X").
Reviews with a green check in the "R" column but no check in the "A" column have been reviewed by at least one core reviewer, but not approved. Core reviewers should keep an eye on these reviews so that they can approve them when they are ready to be merged.
The review choices for core reviewers will look like this:
Core reviewers should feel free to leave a vote of any value for code review, but should not vote in the "Approved" column until the change is ready to be merged. When it is, they should visit (or revisit if they already voted) the review page and leave a vote of +1 for "Approved" to trigger Jenkins trunk gating tests and eventual merging of the change.