Kelly O'Hair's Weblog (blogs.sun.com)
Sunday May 11, 2008
OpenJDK Bug States
Until the OpenJDK project converts to Bugzilla, I thought some more information about how our internal bug tracking system works might help people watching the current situation.
The OpenJDK change requests (CRs) or bugs are currently visible at bugs.sun.com.
There are 11 states for a CR and the normal change of state is the following:
- Dispatched: The initial state for a new CR.
- Incomplete: Something critical is missing from the CR.
- Accepted: CR was accepted, the first step in being investigated and fixed.
- Defer: Work on this CR is on hold.
- Cause Known: A basic understanding of the problem is known.
- Fix Understood: A basic fix is now understood.
- Fix in Progress: The assigned engineer is actively working on the fix or getting it integrated.
- Fix Available: A changeset or the actual fix has been made available in a team area.
- Fix Failed: Something went wrong with the fix.
- Fix Delivered: The changeset or fix has been integrated into the master area and will show up in the next build promotion.
- Closed: There are many reasons why a bug will be in the closed state. It might be verified as fixed, closed as a duplicate, closed as 'not a bug' or closed as 'will not fix'.
The states 1-9 are considered "unresolved", so until a bug becomes "10 - Fix Delivered" or "11 - Closed", it is still considered unresolved. So being "unresolved" may mean that a fix is available, just not in a position to be made part of a formal build promotion.
The bugs.sun.com interface is read-only and somewhat crude, but you can query the bug information, for example the Unresolved JDK Build Subcategory Bugs and RFEs. Hope this helps explain things.
-kto
Posted at 12:25PM May 11, 2008 by kto in Java | Comments[4]
Subscribe!
This process doesn't seem to be working, or perhaps it's just that it isn't always being followed.
I had to add a link to http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2008-June/000207.html to the bug report at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6614100
If I hadn't done that, people would not have known that there was a patch available.
Posted by Andrew Haley on June 09, 2008 at 01:58 AM PDT #
Not sure what process you refer to. Changesets (and Mercurial) are the new kids on the block, and being able to provide an http link to a changeset is a bit foreign to most engineers at this time. Not everyone that delivers or makes a fix available will add that changeset http link to the bug report, that's never been formally required. I'm trying to encourage the habit and if possible even automate this addition to the bug report.
-kto
Posted by Kelly O'Hair on June 09, 2008 at 09:16 AM PDT #
By "the process doesn't seem to be working", I meant that at the time I made the comment the bug was still in State 5 (or State 3, I can't remember) even though a patch had been written, approved, and committed.
If people don't add a hangeset http link to the bug report, I can't see how there is any way that anyone outside Sun can find out how a bug was fixed.
Posted by Andrew Haley on June 10, 2008 at 08:23 AM PDT #
It's currently the developer or the team integrator that would need to manually add this changeset http link to the bug report. Within a month or 2, you should start seeing at least the hotspot ones getting this http link automatically added. Until then, it is what it is.
By the way, anyone can enter a bugid in the search box as you browse the repository to see if there is a changeset with that bugid in it. Works pretty well. But we do ultimately want complete connections back and forth from the bug database and the changesets, eventually anyway.
-kto
Posted by Kelly O'Hair on June 10, 2008 at 03:58 PM PDT #