JDK Updates: Requesting push approval for fixes
Rule 0
An OpenJDK JDK Updates Author, Committer or Reviewer requesting
their fix in a JDK Updates repo MUST label the corresponding
master/parent issue with
jdk<release>u-fix-request
(where <release>
denotes the feature release version, e.g. jdk21u-fix-request) in
the JDK Bug System.
Rule 1
When requesting push approval for a fix the requester must update the JBS issue to add a comment whose first line is "Fix Request". In that comment the requester must describe why it's important to fix this bug, explain the nature of the fix, estimate its risk and describe its test coverage. Additionally the comment should note whether the patch from the JDK Project applies cleanly. If not, the fix MUST be codereviewed in public and a public url to that review MUST be provided in the comment section of the bug report. (Note: for pull requests submitted via github, Skara will add a comment to the JBS issue containing a link to the PR)
Note: The approval process takes place entirely in JBS. Approval emails are no longer required for the jdk-updates project.
If a change requires CSR approval, that approval must be obtained prior to making the push approval request.
Rule 2
If (and only if) approved the label will be updated to
jdk<release>u-fix-yes
.
The fix may then be pushed to the active JDK Updates repo.
All relevant updates will be processed via the bug report.
Rule 3
Any reasonable fix which contributes to the stability, security or performance of the affected line should be considered.
In addition to the above, bugs fitting into one or more of the following categories will usually be accepted for approval:
- CPU fix merges
- TZData updates
- Test fixes
- Changes to root CACerts
- Changes to the build number
- Fixes specific to downstream builders' projects
- i18n / l10n changes