Deprecated

This page is deprecated and it's content is either old or being moved to the OpenJDK Developers' Guide. Please update your links.

Running tests and pushing changes

Read about the Submit repo here.


 

Test analysis and bug handling

The integration_blocker label should be used to indicate that a bug is present in a repository but not present upstreams. When filing a new bug found in hotspot testing, the default should be to add the integration_blocker label. If it is verified (when filing or later) that the new failure is already present upstreams from the repository where it was found the label should be removed and an explicit comment must be added to the bug explaining why the bug is not an integration blocker. A failure seen in a project repo is considered escaped when found in jdk/hs. A failure seen in jdk/hs is considered escaped if seen in jdk/jdk or if older failures are found from a date before the last integration to jdk/jdk.

If an integration blocker escapes from a project repository it will become an integration blocker in jdk/hs.

The testbug label should be used for bugs in tests and test infrastructure. There is no fundamental difference between a test bug and a product bug in the eyes of the gatekeeper. Both are considered integration blockers and both should be handled asap when appearing in the testing.

There are a few ways to figure out if a problem has already escaped a repository:

  • The easiest way is of course if you know which change that caused the problem. Just have a look at the hg log of the upstream repository to see if the change is in there.
  • Searching JBS can give information as well. See if there is more than one bug filed for the issue. If it escaped it is likely that someone else has found it and maybe filed a new bug.
If a bug has escaped from a project repository into jdk/hs, the fix/backout/quarantine should be done in jdk/hs to avoid blocking integration for other Hotspot changes. If a bug escapes jdk/hs into jdk/jdk the fix must go into jdk/jdk.

Integration

If a main bug is targeted to a release and the fix is pushed to a different release, then a backport bug is automatically created. Usually this is a "good thing", e.g., when you are really backporting a fix to an earlier release, but not always... If the main bug is targeted to a later release (due to schedule planning), but someone finds the time to fix that bug in the current release, then the bug should be retargeted to the current release before pushing the fix. However, sometimes we forget to do that.

Here is how to fix that:

In this example a fix was pushed to JDK 10 (a.k.a. the current release) while the JBS bug was targeted to JDK 11 (a.k.a. a future release).


  1. Reopen the backport bug that was created automatically

    • Use a comment like the following (in the reopen dialog):

      Fix was pushed while main bug was targeted to '11'. Reset the main bug to fixed in '10', reset this bug to fix in '11' and closed as 'Not An Issue' since JDK 11 will automatically get this fix from JDK 10.
    • Change the 'Fix Version/s' from '10' to '11'.
    • Close the backport bug as "Not an Issue".
  2. Clean up the main bug

    • Copy the open push notification comment from the backport bug to the main bug, e.g.:

      HG Updates added a comment - 6 hours ago
      URL: http://hg.openjdk.java.net/jdk/jdk/rev/8db54e2c453b
      User: clanger
      Date: 2017-12-11 07:25:20 +0000

    • Add a comment like the following to the main bug:

      Fix was pushed while main bug was targeted to '11'. Reset the main bug to fixed in '10' and copied the hgupdater entry here.
    • Reset the main bug 'Fix Version/s' from '11' to '10'.
    • Resolve the main bug as "Fixed" in build "team" or in build "master" depending on where the fix was pushed. Pushes to 'jdk/jdk' are fixed in build "master" and pushes to other repos are fixed in build "team".

There are several ways to find out if a change has been integrated to jdk/jdk or not. The easiest way is probably to look at the mercurial log in jdk/jdk and see if your change is there:

hg log | grep 1234567

Or, if you don't have a recent clone of jdk/jdk available, look at http://hg.openjdk.java.net/jdk/jdk/