JDK Defect Tracking

Java SE has provided open access to both the submittal and viewing of defects since the 1.1 days. It is considered important that we continue this as we transition to a new tracking system as part of the overall OpenJDK effort. The following provides an overview of what we are trying to achieve in order to scope out the right overall implementation and make sure we have a common understanding/agreement on the roles and usage that we will support in the new defect management system.

Roles

We need to support the needs of a variety of groups that use the current system on a daily basis, while there is some fuzziness and overlap around these roles they make up distinct use cases.

Java Community

We provide open access (no login required) to our bug database (bugtraq) through bugs.sun.com and believe it is important that this type of access continues for both developers, System Admins and others who are looking to understand problems that they may be having with Java applications/infrastructure. There are 100'000s of views a year and we need to enable effective searching and linking to the defects. A key point here is that the person searching for issues may not be a Java expert and so we need to make the process as straightforward as possible so that they can find the error message that is impacting the software they have and understand in which release they might find the fix. The searching/listing functionality we have today is extremely limited (to say the least) and needs to be updated.

We also provide a way for the Community to submit incidents which can turn into defects against the JDK. Until recently those incidents were not public until they had been triaged which caused complaints/confusion as well as a delay in some cases for important issues. We will continue to allow incidents to be submitted without having to login but will will maintain these incidents logically separate from the main set of defects, as today the incidents will become defects once they have been triaged to validate the basic information.

Java Developers

Today for developers who have a OTN login we provide options to comment on, watch/track and vote for bugs. There are 10'000s of votes and comments a year which are in general reviewed and taken into account when addressing bugs. The current implementation is dated and various proposals around improving the usability/effectiveness of the votes and comments have not been made due to inability to change the existing infrastructure, we should look to make these updates as part of this transition along with other requests we have received.

Support Customers

As happens today we will manage and track cases raised as part of commercial support contracts in the same DB. While moving forward most customer specific data will be managed through internal support systems (BugDB) some customer information will need to be associated with the relevant bugs. This means that that information may be restricted to OpenJDK developers and/or subsets of those developers. This will also be the case for contact information for incidents submitted by the community. In addition the bugs that are migrated into the new system contain private information that will continue to remain private.

Release Production

The JDK/JRE releases produced by Oracle will be based off the OpenJDK source base and with fixes coordinated as part of the OpenJDK defect management system, this means that we will need ways in which integrate other tools such as bug approval, test harnesses etc. in order to submit, update and close bugs. For releases such as the security (Critical Patch Update) releases information on the releases will, as happens today, only be available to a limited number of OpenJDK community members.

OpenJDK Community

In addition to OpenJDK developers there will be a variety of groups such as Quality, Sustaining, Localization etc. that will require full access to the defect tracking system.

OpenJDK Developers

OpenJDK developers will have full access to the defect tracking system with the ability to open, edit, close the bugs that are part of the implementation area they own. As noted previously there will be some fields/bugs that may be restricted depending on customer information, information that was confidential previously for the bugs that are migrated over and security concerns.

Our estimates as to the number of users in each role

Submittal of Defects

Community	The community should continue to have the ability to submit incidents, this will be done in a way that allows as much relevant data to be collected in order that the issue can be replicated and addressed. These incidents will be triaged before they become defects (see later section). All information from the community needs to be publicly viewable (no private data for example) but the identification and contact information of the submitter will be kept private. For community members who regularly submit valuable incidents they should have the ability to direct enter the defects they find without them having to be triaged.
CAP	For our early access programs such as CAP participants will be able to directly submit defects
Quality	The quality groups will submit defects through both automated test infrastructure and individually as necessary. This would include quality groups for other groups or companies that are part of OpenJDK
Support	Defects will be opened for the cases that come through paid support, where necessary data will be edited or excluded to ensure privacy of customer data
OpenJDK developers	OpenJDK developers will be able to submit defects as necessary, this should also include members of the expert groups for JSRs

Triage of Incidents

As noted earlier until recently we have not made incidents visible until they had been reviewed internally, while the goal had been to avoid swamping the JDK developers with issues that were not reproducible or duplicates it became obvious that handling this review process in private was a source of upset especially when we incorrectly triaged an incident that should have been converted to a defect. Moving forward the idea is to adopt the model of other projects where issues are triaged through independent verification by other members of the community before they are added to the main set of defects. This will be done by community members providing additional data or voting for the incident. Incidents would be viewable in the same way as defects but tagged so that their status is clear. The transition from incident to defect should be if possible automatic once it has ben validated in some way. Members of the community who have a high percentage of their incidents converted into defects would automatically have their incidents converted into defects. OpenJDK developers should also be able to track incoming incidents in the same was as defects and bring over incidents in a straightforward manner if it is clear that it is something that needs to be addressed.

Ideally the submitter of an incident (who was logged in at the time of submittal) should have the ability to update the incidents they submitted while they are in the triage area or as they are being resolved.

Resolving Defects

OpenJDK developers will have full control over the defects that they own including the ability to close, duplicate, make private etc. This section will likely need to be expanded into a separate document in order to step through the bug lifecycle and the way that the bug system will interact with the other OpenJDK infrastructure will need to be clearly defined.

Release Production

As part of the management of releases it should be possible to tag defects as being required fixes for a release or waiving them for a future release. The size and complexity of the Java SE releases varies quite considerably and being able to track fixes across 4 or more releases is not uncommon.

High Level Architecture

Levels of Access

Users	View	Query	Watch	Vote	Comment	Submit Incident	Submit Defect	Own Defect	View restricted information
Java community (anonymous access)	Y	Y				Y
OTN user	Y	Y	Y	Y	Y	Y
OpenJDK community including developers	Y	Y	Y	Y	Y	n/a	Y	Y	Y

Someone who is part of the OpenJDK community and an Oracle employee will be able to see the restricted data from the bugs that are migrated from our existing bug system.

While the number of access levels may seem unnecessary if we just consider the OpenJDK releases we want to continue with the model that we had since the beginning of Java SE and track the issues for all our deliverables (Source, RIs, TCKs, binaries, products) out of the same system. Today you can search our online system today and find many "internal" issues which detail test failures, where we have staged the wrong binaries etc. etc. It is not uncommon for internal failure to have votes or be escalated (where a support customer expresses strong interest in having a fix) as all the bugs are in general available to view. While this brings constraints around confidentiality of information in the system and broadens the types of issues in the system and the manner in which they are tracked it is believed that maintaining an complete internal shadow system will add more complexity and delay to community seeing what is being fixed and where.

Roadmap

Replicating all the features and functionality we have today will take some time. We are expecting that we will prioritize meeting the needs for the OpenJDK developers and Release Production, closely followed by the ability of the Java Community to search for and submit incidents and finally the commenting/tracking/voting functionality.

To provide feedback please use the OpenJDK web-discuss alias, note you need to subscribe to the alias to be able to post messages.

5th April 2011