Versions Compared

Old Version 33

changes.mady.by.user Christoph Langer

Saved on

compared with

New Version 34

changes.mady.by.user Goetz Lindenmaier

Saved on

Key

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

...

  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 a clean backport, consider backporting those first (within reason).

  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.

      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. Put the jdk11u-fix-request label and add a "Fix Request" comment on the issue, that explains why the fix should be backported, 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 an informed decision for inclusion into the update release.

    2. Wait for maintainer approval, which would manifest as jdk11u-fix-yes label on the issue.

      Code Block
      titleExample Fix Request comment with RFR
      collapsetrue
      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. PR was
acked by monty.
      Code Block
      titleExample Fix Request comment without RFR
      collapsetrue
      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. From the original JBS issue, create a backport JBS issue ("More"→"Create Backport"). Target the backport issue to 11-pool. This issue will be resolved when the change is pushed.
    2. From that 11-pool  JBS 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, 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.  What if the change you want to downport is not public?
    1. Sometimes a change you want to downport is not public in JBS. This means you can see the change and its JBS ID in the Git repository, but you will not find the corresponding issue in JBS.
    2. In such a case, you have to create the corresponding backport issue manually, according to the following recipe:
    3. Create a new issue in JBS with type "Bug" (you can't directly create an issue of type "Backport")
    4. The new issue should have exactly the same summary like the original change. You can take this from the Git "summary" line by stripping the prefixed Bug ID.
    5. It's helpful if the bug description contains a link to the original commit.
    6. Affected version should be one of "8", "11", ...
    7. Under "Linked issues" choose "backport of" and enter the bug id of the change you want to downport into the "Issue" filed (in the format "JDK-XXXXXXX"). After adding this link, it will be not visible. You can only verify that you added it by looking at the histrory. 
    8. Once you've filled out all the other fields, press "Create" and once the issue has been created, edit the issue "Type" and change it from "Bug" to "Backport".
    9. Continue as usual at step 2.

  9. If and only if everything is approved, push the change. This is done using the /integrate command of SKARA on the backport pull request. If you are not an jdk-updates project committer you'll need a committer to sponsor the PR for you.

...