Public Code Review

Preamble

Pre-requisite

Before asking for code review, make sure your fix is applied on the most recent revision of the code you intend to work on, that there are no build errors on the supported platforms for the release you're working on, and that any included or otherwise applicable tests pass without failures on all relevant platforms. If you're not able to build or test on all supported platforms, you MUST let the reviewers know which ones you were able to build and test on, as well as whether you anticipate any issues on the platforms you haven't been able to build and test on.

Rule 0

Code reviews for public JDK 8 Update forests MUST be done publicly: Either through e-mail on jdk8u-dev@openjdk.java.net mailing list, or using some other suitable public mechanism. If a code review is not done on the jdk8u-dev@openjdk.java.net mailing list, as part of the approval request for inclusion of the fix into a public JDK 8 Updates forest, which you MUST send to the jdk8u-dev@openjdk.java.net mailing list, a URL for the public code review MUST be provided.

Rule 1

With modular source code changes in JDK 9, any patch being backported from the JDK Project should have the unshuffle_patch.sh script run against it. If the script runs successfully and if the resulting patch applies without error to the JDK 8 Update repository, then it does not have to be resubmitted for review. In that case the URL for the changeset in the JDK repository will suffice. If any issues are encountered during the unshuffle_patch.sh script execution or during the patch import, a code review for the backport changes should be requested.

Rule 2

If the content of a changeset submitted for review for a public JDK 8 Update forest differs from the corresponding feature JDK changeset, or if there is no corresponding feature JDK changeset, then the changeset MUST be submitted publicly for review:

• A very small changeset MAY be submitted as a simple patch, as described in http://openjdk.java.net/contribute/
• Other than that, changesets SHOULD be submitted as webrevs on the code review server, cr.openjdk.java.net.

Rule 3

A changeset submitted for the JDK 8 Update mainline forest (jdk8u) MUST be reviewed by at least one reviewer. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads.

Rule 4

A changeset submitted for a JDK 8 Update release forest (like jdk8u20, once it's branched off) MUST be reviewed by at least two reviewers. The maintainer responsible for approval of the changeset MAY request additional, specific reviewers to review the changeset, e. g. component leads.

Rule 5

When backporting a changeset from the JDK Project, you SHOULD ensure you have agreement from the original author and reviewers that it's suitable for backporting. You SHOULD also cc the original author and reviewers on the jdk8u-dev@openjdk.java.net mailing list when requesting approval.