• Home
    • View
    • Login
    This page
    • Normal
    • Export PDF
    • Export Word
    • Attachments
    • Page Information

    Loading...
  1. Dashboard
  2. JDK Updates
  3. Main
  4. JDK11u
  5. How to contribute or backport a fix

Page History

Versions Compared

Old Version 43

changes.mady.by.user Goetz Lindenmaier

Saved on Oct 01, 2022

compared with

New Version 44

changes.mady.by.user Goetz Lindenmaier

Saved on Oct 25, 2022

  • Previous Change: Difference between versions 42 and 43
  • Next Change: Difference between versions 44 and 45
  • View Page History

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

OpenJDK 11u uses SKARA (Git) for backporting fixes from later JDK releases since June 2021. The old Mercurial-based workflow is no longer described. Please reach out to the JDK Updates mailing list in case you need help with that.

To prepare for contributing to one of the repositories (<your>/jdk11u-dev, openjdk-bots/jdk17u-dev, <your>/jdk17u etc), enable Pre-submit testing for each of the github repositories!

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. 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 pick up the same issue, you can add a preliminary "Fix request 11u" (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.
      2. Open the link of the original commit in GitHub and issue the /backport command by adding the comment: "/backport jdk11u-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
    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. Enabling GitHub Actions for your personal fork of the jdk11u-dev repository before publishing your branch will provide you with a tier1 test run via GitHub Actions

  4. Create a pull request at https://github.com/openjdk/jdk11u-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 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.

  5. 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 at 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. It is helpful to state in the PR description what changes were needed and why: the difference against original patch, motivations for doing things differently, etc.. The description is addressed to the reviewers of the change who assess whether the change is correct for the update release.

      Code Block
      titleExample PR message
      collapsetrue
      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
  6. Request and await approval for the fix (if the issue is not public, go to step 8 first)
    1. Add a "Fix Request <java version>" comment to the JBS issue that explains why the fix should be backported, gives a risk estimate of introducing new errors, explains the dependencies on other backports (if any), shows what testing was done to verify the backport etc. The goal for the "Fix Request" comment is to give maintainers all the information about the change to make an informed decision for inclusion into the update release. Then put the jdk11u-fix-request label on the JBS issue.  Now the JBS issue will appear in the filters used by the maintainers. The maintainers might remove the label if the issue is not ready to be decided upon.  Add the label again if all preconditions are fulfilled.
    2. Wait for maintainer approval, which would manifest as jdk11u-fix-yes label on the issue. If the maintainers think the change is not good for an update they will add a jdk11u-fix-no label.

      Code Block
      titleExample Fix Request comment with RFR
      collapsetrue
      Fix Request 11u
      
      Backporting this patch eliminates the critical eel overflow.
      The risk is medium. It changes the critical component xyz, where little changes sometimes have unexpected effects. But this only touches abc and not the primary functionality of xyz. Fixing the issue overweights the risk.
      Patch does not apply cleanly to 11u and requires adjustments. 
      Backport requires JDK-8423421 and JDK-8771177 to be applied first.
      Included test passes. Ran tier1 and tier2 and a big application to rule out secondary effects.
      
      
      Code Block
      titleExample Fix Request comment without RFR
      collapsetrue
      Fix Request 11u
      
      Backporting this patch eliminates the eel overflow. 
      Low risk as this only touches tests.
      Patch applies cleanly to 11u. 
      Backport requires follow up issue JDK-8282288.
      New test fails without the product patch, and passes with it. Tier1 and tier2 tests pass with the patch and 8282288.
      

...

Overview
Content Tools
ThemeBuilder

Terms of Use • License: GPLv2 • Privacy • Trademarks • Contact Us

Powered by a free Atlassian Confluence Open Source Project License granted to https://www.atlassian.com/software/views/opensource-community-additional-license-offer. Evaluate Confluence today.

  • Adaptavist ThemeBuilder Powered by Atlassian Confluence 7.13.8
  • Adaptavist ThemeBuilder printed.by.atlassian.confluence
  • Report a bug
  • Atlassian News
Atlassian
Adaptavist ThemeBuilder EngineAtlassian Confluence
{"serverDuration": 209, "requestCorrelationId": "c9b6ae240abb3346"}