1# ANGLE's Code Review Process
2
3This page describes the review process for ANGLE reviewers and committers. For
4instructions on submitting your change list for review, please see
5[ContributingCode](ContributingCode.md).
6
7## Reviewing Changes
8
9The author of a CL may designate reviewers. Please feel free to weigh in on
10changes even if you are not a designated reviewer!
11
121.  To review a change, you can either navigate directly to the URL for the CL,
13    or, if you are one of the designated reviewers, the change will appear in
14    your dashboard at https://chromium-review.googlesource.com/
152.  Review the change listed by looking over the diffs listed in the most recent
16    patch set.
17    *   You may view the diffs either side-to-side, or in unified diff format.
18    *   You can comment on a specific line of code by double-clicking that line,
19        or on the file as a whole by clicking the "Add file comment" icon, which
20        appears above the diff, in the line number column.
21    *   Note that, for CLs submitted as fixes to standing bugs, style issues
22        that pre-exist the CL are not required to be addressed in the CL. As a
23        reviewer, you can request a follow-up CL to address the style issue if
24        you desire. This exception doesn't apply for CLs which implement new
25        functionality, perform refactoring, or introduce style issues
26        themselves.
273.  Once your review is complete, click the "Review" button
28    *   If you are satisfied with the change list as it is, give a positive
29        review (Code-Review +1 or +2).
30    *   If you think the change list is a good idea, but needs changes, leave
31        comments and a neutral review. (Code-Review 0)
32    *   If you think the change list should be abandoned, give a negative
33        review. (Code-Review -1 or -2)
34    *   A +2 code review is required before landing. Only ANGLE committers may
35        provide a +2 code review.
36    *   ANGLE has a 2-reviewer policy for CLs. This means all changes should get
37        a positive review from more than one person before they are accepted.
38        This is most usually handled by reserving the +2 review for the second
39        reviewer to clear the CL.
40    *   If you made comments on the files, the draft comments will appear below
41        the cover message. These comments are not published until you click on
42        the "Publish Comments" button.
434.  Verification and landing:
44    *   If the CL author is not an ANGLE committer, the CL should be verified
45        and landed by a committer. Once verified, the "+1 Verified" status may
46        be added, and the CL may be landed with the "Publish and Submit" button.
47        There should be no need to rebase via the "Rebase Change" button prior
48        to landing.
49    *   If the CL author is an ANGLE committer, they should verify and land the
50        CL themselves.
51    *   Please note: Verification and commit-queue workflow may be subject to
52        change in the near future.
535.  Cherry-picking to other branches
54    *   If the change is needed on other branches, you may be able to land it
55        using the "Cherry Pick To" button on the CL page.
56    *   If this cherry pick fails, you will need to rebase the patch yourself
57        and submit a new change for review on the branch.
58