Page History

...

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. "tier2" provides a larger coverage, if you have resources to run it. Use "make run-test TEST=tier2" to run
   3. Run tests from the area that the patch affects, use "make run-test TEST=<path-to-tests>" to run specific tests
   4. New regression tests that come with the patch should pass
      
      
5. If (and only if) the original patch was modified, get the change reviewed
   1. Note: the change review is not the approval, which you would get at the next step
   2. It is advised to do the review at the jdk-updates-dev mailing list and optionally cc the original mailing list.
   3. The review request should be clearly marked as such: "[11u] RFR <original-bug-id>: <synopsis>"
   4. It is helpful to state what changes were needed and why: the difference against original patch, motivations for doing things differently, etc.

   Code Block
   title Example RFR message collapse true
   Subject: [11u] RFR 8888888: My Hovercraft Is Full Of Eels Hi, Original bug:   https://bugs.openjdk.java.net/browse/JDK-8888888   https://hg.openjdk.java.net/jdk/jdk/rev/88888888 Original patch does not apply cleanly to 11u, because eels are all different sizes and shapes. Notably, I had to change the com/antioch/holy/Grenade.cpp to avoid API that only exists in 12+. 11u webrev:   https://cr.openjdk.java.net/~monty/8888888/webrev.01/ Testing: x86_64 build, affected tests, tier1 Thanks, -Monty

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.
      
      

   Code Block
   title Example Fix Request comment with RFR collapse true
   Fix Request Backporting this patch eliminates the critical eel overflow. Patch does not apply cleanly to 11u and requires adjustments. Backport requires JDK-8423421 and JDK-8771177 to be applied first. 11u RFR: http://mail.openjdk.java.net/pipermail/holy-grail-dev/2019-August/00001.html

   Code Block
   title Example Fix Request comment without RFR collapse true
   Fix Request Backporting this patch eliminates the critical eel overflow. Patch applies cleanly to 11u. New test fails without the product patch, and passes with it. Backport requires JDK-8423421 and JDK-8771177 to be applied first. tier1 and tier2 tests pass with the patch.

7. What if the change needs a CSR?
   1. Manually create a backport issue in JBS, targeted From the original issue, create a backport issue ("More"→"Create Backport") in JBS. Target the backport issue 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. If the CSR is a straight copy of the original CSR, making adaptions as necessary, say so clearly in the issue text, otherwise point out differences. 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.

...