...
All code must be reviewed before being pushed to the repository. The short version of the OpenJFX code review policy is:
- We define a formal "Reviewer" role, similar to the JDK project.
- The code review policies recognize the following different types of changes, with different thresholds for review:
- Simple, low-impact fixes: 1 Reviewer
- Higher-impact fixes: 2 Reviewers + allow sufficient time (1 day recommended) for others to chime in
- Features / API changes: CSR for approving the change, including approval by a "lead"; implementation then needs 2 Reviewers for the code (as with other "higher-impact" fixes above)
- A review can either be done via a webrev posted to http://cr.openjdk.java.net/ (with review comments in JBS or on the mailing list), an in-line diff in the bug report for tiny one or two line changes, or a fix developed in the GitHub sandbox and submitted via a pull request (with review comments in the PR itself). In the latter case, an email must be sent to openjfx-dev announcing the review, and all other review policies must be satisfied, before the PR is merged into the develop branch on GitHub. If so, the PR itself will serve as the review.
...
The review of the implementation follows the same "two reviewer" standard for higher-impact changes as described in category B. The two code reviewers for the implementation may or may not include the Lead who reviewed the CSR. The review / approval of the CSR is an independent step from the review / approval of the code change, although they can proceed in parallel.
3. Streamlined review process for changes developed on GitHub
A GitHub pull-request (PR) targeted to the 'develop' branch of the https://github.com/javafxports/openjdk-jfx repository can serve as the formal review for a fix, instead of a webrev, thus allowing it to be integrated into main line 'jfx-dev' HG repo without an additional review, provided all of the review policies are followed prior to merging the PR into the 'develop' branch. In particular:
...