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:
- Generic Bugzilla documentation. This has not been localized for our instance. We recommend reading Chapter 5-Using Bugzilla at a minimum.
- Specific field information for this instance. Has information on our bug states, priority/severity information, watch users, etc.
A few other notes:
- The system does not require an account to simply view bugs, but does require that you login to edit. Registering for an account is free and requires a valid email address. The site uses SSL to protect your information from network snooping.
- Eventually, we will be adding additional mechanisms to track security issues. Do not file sensitive information here yet.
- The site is still being tuned, so if you see something that needs tweaking or is broken, please let us know.
- There are Bugzilla "watcher" email accounts set up for each component. (e.g. watch-product-component at bugs dot openjdk dot java dot net) If you would like to watch for updates to specific components, set your email watch preferences accordingly.
- New bug reports should still be submitted through the normal channels. Normal bugs submitted to the Bugzilla instance during this period will be closed.
- Use the "sandbox" product to practice using the Bugzilla interface. Please don't pollute the valid categories with test bugs.
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:
- SunFire x4200
- OpenSolaris 2008.11
- Lighttpd 1.4.19
- MySQL 5.0.67
- Perl 5.8.4 with some required Perl modules.
- Bugzilla 3.2.1
Phases of Development
There are three expected major phases, details of which will be expanded as more is understood about the project and platform:
- 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").
- 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.).
- 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:
- Classifications: Optional, but useful when organizing
large groups of products. For the initial rollout, we'll only be
tracking contributions in the primary OpenJDK 6/OpenJDK 7
workspaces, but if the number of components gets large, we may want
to introduce a classification scheme such as the following:
- Primary OpenJDK Projects: those in the main OpenJDK 6/OpenJDK 7 workspaces
- Secondary OpenJDK Projects: those not in the main OpenJDK workspaces
- Misc: Other areas as needed. For example: website bugs, process improvements, OGB bugs, etc.
- Products: Typically represent products or high-level
projects. Products can be optionally grouped into exactly one
classification.
Bugzilla allows for multiple administration groups that can each manage their own product structure (i.e. components, milestones). We could define the products as OpenJDK 6 and OpenJDK 7, but that would require each group administrator be given full access to the entire database. To enable more fine-grained administration, the initial projects will probably be divided along the existing OpenJDK functional group structures (e.g. 2D, AWT, Build, Compiler, Net, Security, etc.). The Secondary projects may be assigned their own product(s). - Components: Each product contains one or more components. This can further categorize functional areas. (e.g. for Security, categories might include general, JSSE, JCE, docs, etc.)
- Versions: Revisions of the product. Initially, that will contain 6 and 7 for OpenJDK 6 and OpenJDK 7 respectively.
- Milestones: Also known as "Target Milestone", these are the releases to which a bug is targeted. I expect these will be major milestones, although could be more specific such as build numbers.
- Custom Fields: Bugtraq has several other fields which we will probably emulate. For example, bugtraq state fields such as "Introduced in Build", "Fixed in Build", "Integrated in Build", and "Verified in Build" can all be used to more specifically identify the fix's progression. When an engineer fixes a bug and places the fix into one of the OpenJDK subrepositories (i.e. awt, corba, tl), the state is now fixed and the field is updated accordingly by the engineer. However, the bug is not marked as Integrated until the subrepository's owner places all outstanding fixes into the Master workspaces and updates the "Integrated In" field.
- Bug States/Resolutions: To better emulate the bug transition states of Bugtraq and ease the eventual linkage between the two systems, several additional states will be added. Full descriptions will be available later, but if you're familiar with the OpenSolaris Bugzilla instance, they may look somewhat familiar.
- Custom Flags: Bugzilla instances can add user-defined
flags that represent some condition that is easy to search. Each
flag has four states (<empty>/?/+/-), the meaning of which
depends on the flag's creator. We plan to add at least one field to
represent whether a contribution has been sponsored.
- +: yes/approved
- -: no/denied
- ?: needs a sponsor, the attached data field describes what is necessary.
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
- bradford dot wetmore at sun dot com
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.
