Labels are case sensitive
When using labels in Jira gadgets (like pie charts, heat maps, and statistics tables) Jira will be case sensitive and treat
openjdk as two different labels. Searching however is case insensitive. This means that if you filter out a set of issues based on a label, and then click that label to see a list of the issues, that list will contain more results than the filtered result shows if there are usages of the label with different casing. This can be very confusing and for this reason the recommendation is to stick with the commonly used case for all labels, regardless of your personal taste for upper or lower case letters.
Used to indicate that an "area" (usually a team or project) is interested in the issue. This label doesn't indicate ownership of the issue. E.g.
|(Area)||Used to indicate that an issue is related to a specific area (usually a feature or project). This label doesn't indicate ownership of the issue. E.g. |
|(Rel)||Used to indicate that a bug would be suitable for backport to (Rel). This is not a decision to backport, just a suggestion / recommendation. E.g. |
Used in the rampdown phases to request approval of changes that requires project lead approval (or similar) to include. (Rel) is the release in question, e.g.
Used to request deferral of changes that requires project lead approval (or similar) to defer. (Rel) is the release in question, e.g.
Further details are found in JDK Release Process.
Used in the rampdown phases to request the late inclusion of an enhancement. (Rel) is the release in question, e.g.
Further details are found in JDK Release Process.
Used to indicate that an issue would be of interest to get integrated in (Rel). E.g.
|(Rel)||Used to indicate an issue that must be fixed in (Rel). E.g. |
|(Rel)||Used to indicate that the issue does not affect (Rel) or later. Could for instance be a bug in code that was removed in (Rel).|
Used to indicate that (Team) has triaged this issue for (Rel). The release is optional, but it is encouraged that all bugs are triaged regularly. Using the release will make it easier to keep track of which bugs has been triaged for each release. E.g.
There are many label variants that include the word triage in some form. The form described above is the only one recommended. Please refrain from using other forms.
|Used to indicate that an issue is related to ahead of time compilation (AoT).|
|Deprecated. Was used to indicate that an issue was related to application class-data sharing (AppCDS). The |
|Used to indicate that an issue is related to the C1 JIT compiler.|
Used to indicate that an issue is related to the C2 JIT compiler.
c2-.* labels are used to identify different c2 features. E.g.
|Used to indicate that an issue is related to class data sharing (CDS).|
Used to indicate that an issue is related to a specific garbage collector in the JVM. E.g.
There are also labels in use to identify different GC features or areas rather than GC algorithms. E.g.
|Used to indicate that this is a Graal issue. (Something that needs to be fixed in Graal rather than OpenJDK.)|
|Reserved for Graal integration umbrella bugs. The automated integration script will break if this label is used for other bugs.|
|Used to identify backport issues automatically created by HG Updater (a script that monitors the hg repositories for changes).|
|Deprecated. Was used to tag bugs found in the HotSpot nightly testing. Since we are now running tiered testing there is no more nightly HotSpot testing. See |
|Used to tag bugs that are found in the "same binary runs", a stress testing method used to find intermittent failures.|
|Deprecated. Was used to identify which HotSpot tier a test failure was seen in. We don't separate HotSpot tiers from other JDK tiers anymore. See |
|i18n||Used to indicate that an issue is related to internationalization (i18n).|
|Used to indicate that a bug is present in a downstream repository but not present in the upstream repository and is therefore blocking integration of downstream changes into upstream.|
Some issues may seem intermittent when looking at test results, even though the reason for failing is actually known. One example is where a test fails consistently on a specific host, or due to specific conditions in the environment. These failures should not be considered intermittent but it may still be valuable to tag these in JBS with one of the labels
A test that should be platform agnostic but is consistently failing on a specific OS would for instance be labeled with
|Bugs that for some reason is wasting engineering time just by existing, or in other ways are causing pain for the maintainers of the JDK. Examples are bugs that occur frequently in testing or test failures that are time consuming to investigate before determining that it is a pre-existing bug.|
|Used to identify a bug with noticeable performance impact. Either positive or negative.|
|Deprecated. Was used to indicate that a failure happened in product integration testing (PIT). Since we are now running tiered testing there is no more PIT. See |
|One or more tests has been problemlisted due to this bug.|
Used to indicate that the issue is a release note. The
Used to indicate wether a change requires a release note or not. The labels are (only) placed on the main JBS issue.
|Used to identify a bug as affecting Java SE startup.|
Used to identify TCK conformance stoppers (e.g. failure of a valid TCK test that exists in a shipped TCK). The release number indicates which release of the TCK that failed. E.g.
|Used to indicate which tier a test failure has been seen in. Lower tiers would in general mean higher urgency to fix the issue. E.g. |
|Used to identify a bug as submitted on bugs.java.com.|
|Used to indicate that an issue is related to ZGC.|