The process we use is
All changes that are not specific to JDK 8 Update MUST go into the JDK Project first. As a special exception, a change MAY go into JDK 8 Update if it is at the same time also proposed for inclusion into the JDK Project.
jdk8u/jdk8u-dev, the always open mainline JDK 8 Update forest, is maintained by the Project Lead. Exceptions to that are e.g. specific release repositories, where the Project Lead MAY delegate that authority.
Changes submitted for a JDK 8 Update forest MUST go through code review, and MUST be approved by the maintainer for that forest. The maintainer of a forest MAY delegate that authority, allowing for approvals to happen in a more finely granular fashion - per repository, for example.
If the change is an enhancement, then a separate enhancement backport request MUST be approved by the maintainer for that forest prior to the change being submitted for code review and final maintainer approval.
Maintainer approvals for public JDK 8 Update forests MUST take place on the email@example.com mailing list. Code reviews SHOULD take place on that list - if they take place somewhere else, as part of the approval request a URL for the public code review MUST be provided.
A maintainer for a forest MAY pre-approve changes undergoing code review in JDK Project for commit to their forest in JDK 8 Update.
A maintainer for a forest MAY request additional reviews for changes to be performed before it is approved for their forest.
A maintainer for a forest SHOULD coordinate with the appropriate stakeholders to determine whether changes are appropriate for their forest.
For changes submitted for inclusion into a public JDK 8 Update forest, the corresponding bug tracker entry SHOULD be publicly visible.
If the corresponding bug tracker entry is not publicly visible for a change submitted for inclusion into a public JDK 8 Update forest, the submitter SHOULD provide guidance for code review.