Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Minor workflow additions: picking up remote changesets

...

  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 e.g. by 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> > <bugid>.patch"

  3. Apply the exported patch to the target repository (mostly jdk11u-dev), e.g. by using the mercurial mq extension: "hg qimport <bugid>.patch && hg qpush"
    1. Make
    2. This approach will make sure that the changeset metadata is kept (original authors, Reviewed-by lines, etc.)
    3. Most convenient to use Mercurial mq extension: "hg qimport <bugid>.patch && hg qpush"
    4. 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 on the mailing list.
    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 doing things differently, etc.

  6. Request and await approval for the fix.
    1.  Put the jdk11u-fix-request tag and add a "Fix Request" comment on the issue, that explains why the fix should be backported, what testing was done, a risk estimate, etc.
    2. Wait for maintainer approval, which would manifest as jdk11u-fix-yes tag on the issue.

  7. If 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.

...