JDK 7 Updates: Ground Rules

Created by Dalibor Topic, last modified by Iris Clark on Apr 25, 2023

After a new Project Lead was not identified and several months of inactivity, the Project was dissolved Apr 2023. Discussion about reinstating a JDK 7 Updates Project may be held on discuss.

Rule 0

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 Andrew Haley.

Rule 1

Any change that is not specific to JDK 7 Update MUST go into the JDK feature release code line first. The change MUST then be backported to the different JDK Update forests starting with the latest family version first. As a special exception, a change MAY go into the JDK 7 Update forest if sufficient reasons are given for not forward porting it or if forward port planning is already in progress.

Rule 2

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.

Rule 3

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.

Rule 4

Maintainer approvals for public JDK 7 Update forests MUST take place on the jdk7u-dev@openjdk.org 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.

Rule 5

A maintainer for a forest MAY pre-approve JDK 7 Update changes undergoing code review for a later JDK release family version.

Rule 6

A maintainer for a forest MAY request additional reviews for changes to be performed before it is approved for their forest.

Rule 7

A maintainer for a forest SHOULD coordinate with the appropriate stakeholders to determine whether changes are appropriate for their forest.

Rule 8

For changes submitted for inclusion into a public JDK 7 Update forest, the corresponding bug tracker entry SHOULD be publicly visible.

Rule 9

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.

No labels