Versions Compared

Old Version 8

changes.mady.by.user Joe Darcy

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.

...

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

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.

Evolution and time horizon

JBS holds issues dating back nearly 20 years in the past and the information in JBS today is expected to be of interest for more than 20 years into the future. Therefore, a long-term and disciplined perspective will be used when evolving the system. For example, adding new fields will be approached with caution and the information stored in any new fields will need to be expected to be of interest in five to ten years time.

JIRA Version

At the time of external launch, JBS is running JIRA 5.2. For general questions about using JIRA, refer to the extensive documentation available for that JIRA release. Over time, JBS is expected to upgrade to newer versions of JIRA.

Projects

At the highest level, bugs in JBS are grouped into top-level projects. At external launch, there are two public projects in JBS:

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

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

An OpenJDK project may request that a JBS project be created to host its bugs by sending an email to ops@openjdk.java.net. 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.

Common Features across Projects

Issue Types

When filing a new bug, there are five feature types to choose from:

  • 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 multi-release support.
  • New feature: Reserved for future use

The above issue types can by further refined into Subtasks. A Subtask is a issue type used to track breaking up an issue (not just a task!) into smaller pieces. The Subtasks can be resolved individually and then the parent issue can be resolved after all its Subtasks are resolved.

State model

Two fields represent the primary state of an issue, Status and Resolution. In JBS, a number of additional fields are used to hold substatus information: Understanding for substatus values of the In Progress Status and Verification for substatus information about how a bug resolved with a fix was transitioned to a Closed Status.

Status

The basic state model used in JBS includes five values for the Status field:

  • After creation, issues start out in the New state.
  • After triage, a New issue transitions to being Open
  • Once work starts on an Open issue, it moves to In Progress. An In Progress issue can hold further substate information in the Understanding field to indicate Cause Known or Fix Understood.
  • After an In Progress issue is resolved, it moves to the Resolved state. For JDK release Projects, typically the transition to Resolved is performed automatically as a result of pushing a fix to an Hg repository for a particular release.
  • After being verified, Resolved bug moves to the Closed state. The Closed state is a terminal state and no further bug transitions are expected once a bug is closed.

Several additional fields record more specialized status information.

Understanding

When an issue has a status of In Progress, the Understanding field can be optionally used to further refine what is known about the bug:

  • Cause Known: the cause of the issue has been determined.
  • Fix Understood: in addition to the cause being known, the way to fix the problem is understood.

Resolution

Once an issue is Resolved or Closed, the Resolution field is also set. If an issue is resolved by changing a source code repository, the Resolution field is set to Fixed. Other commonly used Resolution values are Won't Fix, Duplicate, Incomplete, Cannot Reproduce, and Not an Issue.

Incomplete Issues

An incomplete issue is one where there is insufficient initial information for the assignee to make further progress. JBS distinguishes between two classes of incomplete issues: ones where more information is expected, and ones where more information is not expected.

An incomplete bug where more information is expected is modeled as:
Resolution = Incomplete, Status = Resolved
In this state, the submitter should provide additional information.

If no further information is provided in a reasonable period of time, an incomplete issue can transition to a closed state. An incomplete bug where more information is expected is not modeled as:
Resolution = Incomplete, Status = Closed

Closing as a Duplicate

Many issues are filed in JBS more than once. When the same issue is filed repeatedly, one issue should be closed as a duplicate of another. To close a bug as a duplicate:

  • 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)

...

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

Evolution and time horizon

JBS holds issues dating back nearly 20 years in the past and the information in JBS today is expected to be of interest for more than 20 years into the future. Therefore, a long-term and disciplined perspective will be used when evolving the system. For example, adding new fields will be approached with caution and the information stored in any new fields will need to be expected to be of interest in five to ten years time.

JIRA Version

At the time of external launch, JBS is running JIRA 5.2. For general questions about using JIRA, refer to the extensive documentation available for that JIRA release. Over time, JBS is expected to upgrade to newer versions of JIRA.

Projects

At the highest level, bugs in JBS are grouped into top-level projects. At external launch, there are two public projects in JBS:

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

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

An OpenJDK Project may request that a JBS project be created to host its bugs by sending an email to ops@openjdk.org. 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.

Common Features across Projects

Issue Types

When filing a new bug, there are five feature types to choose from:

  • 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 multi-release support.
  • New feature: Reserved for future use

The above issue types can by further refined into Subtasks. A Subtask is a issue type used to track breaking up an issue (not just a task!) into smaller pieces. The Subtasks can be resolved individually and then the parent issue can be resolved after all its Subtasks are resolved.

State model

Two fields represent the primary state of an issue, Status and Resolution. In JBS, a number of additional fields are used to hold substatus information: Understanding for substatus values of the In Progress Status and Verification for substatus information about how a bug resolved with a fix was transitioned to a Closed Status.

Status

The basic state model used in JBS includes five values for the Status field:

  • After creation, issues start out in the New state.
  • After triage, a New issue transitions to being Open
  • Once work starts on an Open issue, it moves to In Progress. An In Progress issue can hold further substate information in the Understanding field to indicate Cause Known or Fix Understood.
  • After an In Progress issue is resolved, it moves to the Resolved state. For JDK release Projects, typically the transition to Resolved is performed automatically as a result of pushing a fix to an Hg repository for a particular release.
  • After being verified, Resolved bug moves to the Closed state. The Closed state is a terminal state and no further bug transitions are expected once a bug is closed.

Several additional fields record more specialized status information.

Understanding

When an issue has a status of In Progress, the Understanding field can be optionally used to further refine what is known about the bug:

  • Cause Known: the cause of the issue has been determined.
  • Fix Understood: in addition to the cause being known, the way to fix the problem is understood.

Resolution

Once an issue is Resolved or Closed, the Resolution field is also set. If an issue is resolved by changing a source code repository, the Resolution field is set to Fixed. Other commonly used Resolution values are Won't Fix, Duplicate, Incomplete, Cannot Reproduce, and Not an Issue.

Incomplete Issues

An incomplete issue is one where there is insufficient initial information for the assignee to make further progress. JBS distinguishes between two classes of incomplete issues: ones where more information is expected, and ones where more information is not expected.

An incomplete bug where more information is expected is modeled as:
Resolution = Incomplete, Status = Resolved
In this state, the submitter should provide additional information.

If no further information is provided in a reasonable period of time, an incomplete issue can transition to a closed state. An incomplete bug where more information is expected is not modeled as:
Resolution = Incomplete, Status = Closed

Closing as a Duplicate

Many issues are filed in JBS more than once. When the same issue is filed repeatedly, one issue should be closed as a duplicate of another. To close a bug as a duplicate:

  • Select the Close workflow action.
  • Set Resolution to Duplicate.
  • 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.)

...

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 includesother 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
  • 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 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.

  • : 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 include: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:

...

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

...