Page History

...

1. Check the original JBS issue on https://bugs.openjdk.org/
   1. Carefully check linked issues and whether there are follow-up fixes that need to be brought with the backport. See below how to handle fixes depending on each other.
   2. If there are relevant issues that prevent a clean backport, consider backporting those first (within reason).
   3. To avoid others picking up the same issue, you can add a preliminary "Fix request 11u|17u" (see step 6.) comment saying that you work on this.  Once you reach step 6.), just edit the comment and add the required information.
2. Create the backport commit
   • Option 1 - Use the /backport comment command on GitHub:
     1. Make sure GitHub Actions is enabled for you on the OpenJDK Bots jdk11u-dev repository resp. OpenJDK Bots jdk17u-dev repository.
     2. Open the link of the original commit in GitHub and issue the /backport command by adding the comment: "/backport jdk11u-dev" or "/backport jdk17u-dev"
     3. For a clean backport, the bot will provide you with a branch in his own repository and a link to create a pull request. If the backport needs manual resolving, it will provide you with instructions, similar to option 3.
   • Option 2 - Use SKARA CLI tooling:
     1. Create a branch for your backport, e.g. "git checkout -b my-backport-branch master"
     2. "git backport --from https://github.com/openjdk/jdk <commit-sha>". See the SKARA Wiki for more info.
     3. If necessary, resolve changes and follow the instructions.
   • Option 3 - Use plain Git to create the change:
     1. Create a branch for your backport, e.g. "git checkout -b my-backport-branch master"
     2. "git fetch --no-tags https://github.com/openjdk/jdk <commit-sha>"
     3. "git cherry-pick --no-commit <commit-sha>"
     4.  If necessary, resolve changes.
     5. "git commit -a -m "Backport <commit sha>"
3. Test the patch

Testing is very important. Your backport is very close to the customer, and there are few safety nets. In comparison, patches for the mainline head release do get a lot more cooking time before seeing broad adoption.

Don't rely on maintainers doing testing should make sure that your new functionality works, but, more important, it must make sure that you do not break anythingfor you! Maintainers are humans too. You should know your patch best and must make sure it works and does not introduce regressions. It should not break other platforms, other GCs etc.  Testing of a change with low risk should comprise at least:

1. 1. "tier1" tests should be passing pass at all times, use . Use "make run-test TEST=tier1" to run. . You should test both debug- and release builds. Don't just test debug, or worse, just release!
      1. If your patch changes platform-dependent code, test your patch on as many of those platforms as you have available. If you cannot test every platform but feel that tests are needed, clearly state so in the PR or in the Fix Request. Maintainers then will strive to fill the testing holes for you.
   2. "tier2" provides a larger coverage if you have the 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. Enabling GitHub Actions for your personal fork of the jdk11u-dev repository before publishing your branch will provide you with builds and a tier1 test run via GitHub Actions on many platforms.  If tests are failing, analyze why they are failing and share this information.
      
      
2. Create a pull request at https://github.com/openjdk/jdk11u-dev | https://github.com/openjdk/jdk17u-dev
   
   1. If you have created a backport via Option1, the /backport command, and the backport was clean, you can use the provided link to create a PR
   2. In all other cases, push the new branch to your fork of https://github.com/openjdk/jdk11u-dev | https://github.com/openjdk/jdk17u-dev
   3. and open a PR. You can do this in one step via the SKARA command "git pr create --publish". If it is a backport, make sure the title of the PR is "Backport <SHA hash of original commit>" to have the bots correctly recognize your change as a backport.
      
      
3. If your patch is not a clean backport (labeled as clean by the bots), get the change reviewed by some jdk-updates reviewer
   
   1. Note: the change review is not the approval, which you would get at the next step
   2. The PR message is automatically posted to the jdk-updates-dev mailing list. You might optionally cc the original mailing list or other OpenJDK mailing lists to get some more attention to your PR by using the /label command.

   3. In case of a backport state in the PR description what changes were needed and why: the difference against the original patch, motivations for doing things differently, etc... The description is addressed to the reviewers who assess whether the change is correct for the update release.

      Code Block
      title Example PR message collapse true
      Hi, This is a backport of JDK-8888888: My Hovercraft Is Full Of Eels 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+. Testing: x86_64 build, affected tests, tier1 Thanks, -Monty

4. Request and await approval for the fix (if the issue is not public, go to step 8 first)

...