OpenJDK Bugzilla

The OpenJDK Bugzilla instance is now live!

OpenJDK contributions are now being tracked on our OpenJDK Bugzilla instance at:

For more information, please see:

A few other notes:

Goal

To produce a Bugzilla instance in which OpenJDK contributions, bugs and RFEs can be submitted, tracked, and modified by people both internal and external to Sun.

The OpenSolaris project has already gone through much of the same effort that we are now facing. We plan to use some of their recommendations in our own processes. Also high on the priority list is to use the same open source software solutions that we are encouraging our customers to adopt.

There is still much to learn about Bugzilla's capabilities that will affect this page, so consider this to be a living document that will be enhanced as time allows. As we get more familiar with day-to-day operation of such a system, we will adjust our procedures just as the OpenSolaris team is currently doing.

Architecture

A SLMP-based (Solaris/Lighttp/MySQL/Perl) (as opposed to LAMP ) implementation of Bugzilla. Our current implementation consists of:

Phases of Development

There are three expected major phases, details of which will be expanded as more is understood about the project and platform:

  1. Provide tracking of OpenJDK contributions. The initial scope and goals of this phase are very limited: release a Bugzilla instance into the open and begin tracking patch contributions from developers without push access to the OpenJDK 6 and 7 forests. The primary goal of this phase is to further open our development processes, and prevent submissions from getting lost in the mailing list archives. The ability to track regular OpenJDK bugs will occur in later phases. At rollout, there will be no connection between Bugzilla and Bugtraq (Sun's primary internal bug tracking system, also known by its primary user application: "Bugster").
  2. Expand to a more general bug tracking solution for OpenJDK bugs. This should include most (if not all) OpenJDK projects, not just those that are part of the primary OpenJDK workspaces (e.g. audio engine, modules, new(new)-I/O, Zero, etc.).
  3. Connect to our existing internal bug tracking system. This will allow Sun's Support/Sustaining group and other teams to continue to use their tools and processes without major disruptions.

Note: phase 2 and 3 may be combined into one.

The initial rollout of phase 1 (OpenJDK source contributions for existing bugs ) is expected in early February, 2009. Until later phases of this project are complete, new bug reports should still be submitted through the normal channels. Bugs submitted to the Bugzilla instance during phase 1 will be closed.

As we add bug categories, additional administrators will be identified and granted the power to maintain their functional areas (such as adding new components and milestone versions).

Initial Bugzilla Organization Layout

Describing bugs in Bugzilla is somewhat flexible in that one can add custom fields and bug transition states, but many parts of the data categorization are static. Here is the proposed initial layout, but it is subject to discussion and reorganization if experience shows a better way to do things:

Again, this is just a proposed initial layout, and not all fields will be set at rollout. These are all subject to discussion and will be modified based on experience and feedback.

Primary Contact

FAQ's

Q. Why aren't we using Atlassian Pty. Ltd.'s Jira, the defect tracking solution used by other Open Source efforts at Sun? It's free to Open Source projects. Or something else other than Bugzilla?

A. Bugzilla is the system of choice by many of our external collaborators. We will be adding some additional states and fields to more closely match Sun's internal bug tool states, but Bugzilla is a platform that is well understood and heavily used in the larger Open Source community.

The OpenSolaris community went through an extensive review of the currently available options and settled on Bugzilla. We can take advantage of work already completed or being planned. During later phases of this project, we will be linking the Bugzilla instance with Bugtraq. There is already an effort underway by the OpenSolaris team to provide such a link, and we have already begun to collaborate. By standardizing on the same software, the various groups will not have to reinvent the wheel when they want to add a similar connection. We hope to bring this functionality online as soon as possible as maintaining two different separate databases is just not efficient.

The other primary reason: we want to fully embrace the Open Source paradigm, and simply put, Jira is not Open Source.

Q. Why not use Bugzilla exclusively and get rid of Bugtraq?

A. Our bug reports might contain confidential data (e.g. customer information, crash dumps that contain proprietary information, etc.), and thus can't be in the open. The second reason is that many of Sun's customer support systems are based on Bugtraq, and would have to be reimplemented just for our organization.

Q. For Sun developers, how does this affect Sun's internal bug tracking? Does this mean I'll have to watch two bug tracking databases? Why not one? And what about Sun's internal tools for tracking escalations, customer calls, etc.? How are they going to be tied into this system?

All good questions, and the simple answer is, "We're working on it. We don't know...yet." We are still gaining experience with Bugzilla and how well it will play with our existing tracking systems. These questions will be addressed as latter parts of the system are added.

It is anticipated that there will be a one-way data bridge between the Bugzilla and Bugtraq systems. When a bug report is created in Bugzilla, a corresponding shadow bug can be created in Bugtraq as necessary. Bugzilla is not strong at tracking fixes going into multiple update releases, so we will probably continue to use Bugtraq which handles multiple releases quite well. Thus all of our internal boundary systems (customer support, reporting) should operate as usual.

But again, this is all preliminary, and details will be filled in over time.

Q. Is jcheck (the OpenJDK bug description sanity checker) going to be updated to understand these new bug numbers?

Finally, an easy one. Of course! It'll be a "One Line Change" to a shell script.

Documents

OpenSolaris Defect Tracking System Requirements

OpenSolaris Defect Tracking System Selection Announcement