Versions Compared

Old Version 3

changes.mady.by.user Tony Squier

Saved on

compared with

New Version Current

changes.mady.by.user Iris Clark

Saved on

Key

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

...

The JDK bug system (JBS) hosted at http://bugs.openjdk.java.netorg/ is a JIRA instance which provides bug tracking for Projects in the OpenJDK Community. A large fraction of the bugs are associated with a JDK Release Project, such as JDK 8, and are resolved by changes to the source code for such a Project.

...

Bugs for some closed source technologies included in Oracle's JDK, but not included in OpenJDK, are also tracked in JBS. This continues and expands a long-standing practice of publishing bug information about closed source code on the historical bugs.sun.com, a practice that is as old as Java itself.

...

OpenJDK Roles, Groups, and Projects are explained in the OpenJDK Bylaws. This JBS guide will use terms defined in the bylawsBylaws; the bylaws Bylaws should be consulted for details.

An individual with at least one OpenJDK Project role of Author or higher has sufficient cause to get a JBS account. A JBS account grants an individual general read and write access to issues, including the ability to file new issues, transitioning issues among the states of the workflow, adding comments, changing field values (including adding and removing labels). The holder of a JBS account can also by be the assignee of an issue.

...

At the time of launch, self-service account creation is not supported. Users without an account can browse JBS anonymously or use bugsbugreport.sunjava.com to view a time-delayed and simplified snapshot of bug state.

Design considerations

Users without an account can also use bugreport.java.com to submit an issue. When such an issue is submitted, a record is created in the Java Incidents (JI) project in JBS; at the time of launch, the JI project is not publicly visible. Issues in the JI project have an identifier like JI-9XXXXXX, where the numeric portion corresponds to the bug identifier sent back to the submitter. After an initial triage process, if the incidents needs further review, it can be transferred to be an issue in the JDK project. When such a transfer occurs, the issue gets a new identifier in the JDK project (JDK-8YYYYYY) but references to the original JI-9XXXXXX number will be redirected.

Design considerations

The design of JBS was informed by Sun's legacy bug system used for JDK bugs, the use of JIRA by the JavaFX team, the OpenJDK bugzilla instance, and various other bug tracking systems. The design of JBS was informed by Sun's legacy bug system used for JDK bugs, the use of JIRA by the JavaFX team, the OpenJDK bugzilla instance, and various other bug tracking systems. For JBS, the natural JIRA way for modeling a condition was chosen by default. Configuration changes were favored over customizations. Customizations were considered only when configuration changes could not achieve functionality deemed necessary for JBS.

...

  • CODETOOLS: hosts bugs for jcheck, jtreg, and miscellaneous other utilities.

  • JDK: host bugs for past, present, and future JDK release projects.

An OpenJDK projectProject may request that a JBS project be created to host its bugs by sending an email to ops@openjdk.java.netorg. In many cases, an existing JBS project should be used rather than creating a new JBS project. For example, a new JDK release would use the existing "JDK" project in JBS rather than creating a new project.

A new JBS project can request a component / subcomponent configuration suitable for that effort. A particular project should not expect to be granted further customizations, such as a novel set of status values.

...

  • Bug: a defect or flaw
  • Enhancement: an improvement to an existing feature
  • Task: An item whose resolution does not involve changing the source code repositories.
  • Backport: used in JBS as part of multiple multi-release support.
  • New feature: Reserved for future use

...

  • Select the Close workflow action.
  • Set Resolution to Duplicate.
  • Set Linked Issues to "is duplicated by"
  • Add ID of reference bug (which might remain open)

...

  • Set Linked Issues to "duplicates"
  • Add ID of reference bug (which might remain open)

Normally the issue with the most information should be kept open; this is often the oldest issue.

...

  • Verified: the fix has been successfully verified. Verification might include checking that the regression test for a fix passes on all platforms of interest.
  • Not verified: the verification process was skipped for the fix.
  • Fix failed: the fix is faulty. (For JDK Release Projects, a failed fix is left in a state of (Status = Closed, Resolution = ResolvedFixed, Verification = Fix Failed) and a new bug is opened to cover the aspects of the fix that are failed, partial, or incorrect. In JDK Release Projects, an issue number can only be used for at most one push to a given repository. Therefore, if the original bug were reopened, it could not be used to push an updated version of the fix.)

...

  • the fix.)

Field Summary

Priority

The highest priority bugs are P1. The lowest priority bugs are P5. Specific criteria for determining priority may vary by project.

Textual fields

There are several fields in jbs which store textual information about an issue.

...

  • regexLabel: Matches labels with a regular expression.
    Example: labels stating with "8":
    labels in regexLabel ("8.*")
  • regexOption: Matches option with a regular expression.
    Example: Finds all issues where the os field starts with "solaris":
    os in regexOption ("solaris.*")
  • regexVersion: Matches version field types with a regular expression.
    Example: Finds all issues with a fixed version starting with "7u"
    fixVersion in regexVersion ("7u.*")

...

  • version field types with a regular expression.
    Example: Finds all issues with a fixed version starting with "7u"
    fixVersion in regexVersion ("7u.*")

Anchor
multireleasetracking
multireleasetracking
Multi-release tracking

In stock JIRA, the fixVersion/s field is used for tracking whether or not a fix has been applied to multiple releases. In other words, the status of a fix across all releases is stored in a single issue. For the purposes of the JDK, this was judged as not providing an adequate level of detail. Information of interest for JDK bug tracking across releases includes

  • the release
  • assignee for the release
  • status and resolution for the release
  • release-specific comments

Storing this information allows the bug database to easily answer questions such as:

  • Does an issue impact the release I'm managing? / What releases does the issue need to be addressed in?
  • Who needs to fix this issue? / Am I on the hook for fixing this issue?

The solution above is implemented in JBS using a custom Backport issue type along with a custom Backport link type. Backports are full issues, but only a few fields are expected to be set:

  • fixVersion: indicates which specific release a backport is targeting or fixed in
  • assignee: holds the engineer responsible for the backport
  • Status and Resolution: hold the

In stock JIRA, the fixVersion/s field is used for tracking whether or not a fix has been applied to multiple releases. In other words, the status of a fix across all releases is stored in a single issue. For the purposes of the JDK, this was judged as not providing an adequate level of detail. Information of interest for JDK bug tracking across releases includes

  • the release
  • assignee for the release
  • status and resolution for the release
  • release-Release specific comments

Storing this information allows the bug database to easily answer questions such as:

  • Does an issue impact the release I'm managing? / What releases does the issue need to be addressed in?
  • Who needs to fix this issue? / Am I on the hook for fixing this issue?

The solution above is implemented in JBS using a custom Backport issue type along with a custom Backport link type. Backports are full issues, but only a few fields are expected to be set:

  • fixVersion: indicates which specific release a backport is targeting or fixed in
  • assignee: holds the engineer responsible for the backport
  • Status and Resolution: hold the status and resolution for the release
  • Release specific comments: such as ones added by Hg Updater

When viewing the master bug, its backports and grouped together in a tabular format.

As used with Backports, semantically the Fix Version/s field has a single value. This constraint is not currently enforced in the database used by JBS, but may be enforced in the future.

The bug numbers of backports should not be used in changeset comments when a fix is pushed. The bug number of the master issue should be used in changeset comments for all releases into which a fix is pushed.

  • : such as ones added by Hg Updater

When viewing the master bug, its backports are grouped together in a tabular format.

As used with Backports, semantically the Fix Version/s field has a single value. This constraint is not currently enforced in the database used by JBS, but may be enforced in the future.

The bug numbers of backports should not be used in changeset comments when a fix is pushed. The bug number of the master issue should be used in changeset comments for all releases into which a fix is pushed.

(Note that a backport from an earlier release to later one, such as JDK 7u6 to JDK 8, is just a backport going in a negative direction.)

Further Note: The 'hgupdate-sync' label is used to denote bug records which are already fixed in a previous release. When code lines are synced a new backport record will be created with the hgupdate-sync label to capture the sync activity. For the most part, such records can be ignored since they indicate that the issue was resolved in an earlier update release.(Note that a backport from an earlier release to later one, such as JDK 7u6 to JDK 8, is just a backport going in a negative direction.)

JDK Project

Much of the work in OpenJDK occurs in JDK release Projects which use the "JDK" project in JBS. Therefore, This section will discuss some of the particulars of the JDK project.

...

The main top-level components of the JDK product product (with main corresponding OpenJDK lists, if any) include:

For the libs areas, the primary name of the subcomponent will be the package of the API in question. When a more detailed classification within the technology area of a package is needed, the package name will be followed by a colon (":") and a name for the more detailed area. For example, in the core-libs component, there will be subcomponents like:

...

  • tbd_major and tbd_minor: used to target a fix to some unspecified major or minor release, respectively.
  • 7-pool, 8-pool, etc.: some unspecified future update release in a particular update train.

When a bug is actually fixed, the fixVersion field must be changed to a specific release value rather than some general value. The Hg updater process will perform this task.

The special version values like tbd_minor should not be used in the affectedVersion field; only version values corresponding to actual releases should be used.

When a bug is actually fixed, the fixVersion field must be changed to a specific release value rather than some general value. The Hg updater process will perform this taskJBS issue is discussed on an OpenJDK mailing list, such as a review request, it is recommended to include a link to the OpenJDK thread in a comment in the JBS issue.

Questions and Comments

General questions about JBS can be sent to discuss@openjdk.java.netorg.

Feature requests for JBS itself can be sent to ops@openjdk.java.netorg.

Conclusion

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
— Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid

...