How to contribute a fix

This page outlines the detailed recipe of what to do with a fix.

There are two general types of fixes:

• backports: most commonly, a change for OpenJDK 11 updates is a backport of a change that has been made in a higher OpenJDK version. Start the recipe from Step 1.
• new fixes: rarely, there is a need for a net new change for OpenJDK 11 updates, e.g. because a fix would not apply to higher OpenJDK versions that are in maintenance. Start the recipe from Step 4.

Important: The whole process is driven by the backport requester/contributor. Nothing here assumes that somebody else would do the work. If you are not the OpenJDK Author, that is, you don't have a JBS user account, you'll have to ask for help for steps 6 and 7 (working with JBS to put appropriate metadata). If you are not the OpenJDK Updates Project Committer, you'll have to do the same for step 8 (pushing the change). The regular place to ask for help is JDK Updates mailing list. Regular contributors would eventually gain the necessary privileges to avoid this overhead.

Contribution recipe:

1. Check the original JBS issue on https://bugs.openjdk.java.net/
   1. Carefully check linked issues whether there are follow-up fixes that need to be brought with the backport.
   2. If there are relevant issues that prevent clean backport, consider backporting those first (within reason).
   3. Open the link to the original commit and note its repository and changeset number.
      
      
2. Export the original commit from the original repository 
   1. Locally: "hg export -r <changeset number> --git > <bugid>.patch"
   2. From the remote repo: "wget https://hg.openjdk.java.net/jdk/jdk/raw-rev/<changeset-id> -O <bugid>.patch"
      
      
3. Apply the exported patch to the target repository (mostly jdk11u-dev):
   1. Make sure that the changeset metadata is kept (original authors, Reviewed-by lines, etc.)
   2. Most convenient to use Mercurial mq extension: "hg qimport <bugid>.patch && hg qpush"
   3. Resolve the patch and make necessary adaptions if it doesn't apply cleanly.
      
      
4. Test the patch
   1. "tier1" tests should be passing at all times, use "make run-test TEST=tier1" to run
   2. Run tests from the area that the patch affects, use "make run-test TEST=<path-to-tests>" to run specific tests
   3. New regression tests that come with the patch should pass
      
      
5. If the original patch was modified, get the change reviewed
   1. It is advised to do the review at the jdk-updates-dev mailing list and optionally cc the original mailing list.
   2. The review request should be clearly marked as such: "[11u] RFR <original-bug-id>: <synopsis>" 
   3. It is helpful to state what changes were needed and why: the difference against original patch, motivations for doing things differently, etc.
      
      
6. Request and await approval for the fix
   1. Put the jdk11u-fix-request label and add a "Fix Request" comment on the issue, that explains why the fix should be backported, contains the link to backport RFR (if applicable at step 5), the dependencies on other backports (if any),  shows what testing was done to verify the backport, gives a risk estimate, etc. The goal for the "Fix Request" comment is to give maintainers all the information about the backport to make the informed decision for inclusion into update release.
   2. Wait for maintainer approval, which would manifest as jdk11u-fix-yes label on the issue.
      
      
7. What if the change needs a CSR?
   1. Manually create a backport issue in JBS, targeted to 11-pool. This issue will be resolved when the change is pushed.
   2. From that 11-pool issue, create a new CSR and copy/paste the contents from the original CSR, making adaptions as necessary. The new CSR should also have version 11-pool.
   3. Run the CSR through its process to get it approved.
      
      
8. If and only if everything is approved, push the change.