JDK 7 Updates: Ground Rules
This process is subject to change. Changes MUST be approved by Project Lead and Technical Lead. Changes considering development in OpenJDK MUST be publicly discussed on the jdk7u-dev mailing list prior to approval to allow for public feedback. Project Lead is Dalibor Topic, Technical Lead is Edvard Wendelin.
All changes that are not specific to JDK 7 Update MUST go into JDK 8 first. As a special exception, a change MAY go into JDK 7 Update if it is at the same time also proposed for inclusion into JDK 8.
The always open mainline JDK 7 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 7 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.
Maintainer approvals for public JDK 7 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 for JDK 8 for commit to their forest in JDK 7 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 7 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 7 Update forest, the submitter SHOULD provide guidance for code review.