By kto on Nov 17, 2008
Yeah yeah, I haven't done a blog in a while.
For the most part I work on build related bugs in most of the JDK releases, so I thought it might be helpful for people to see what kind of build bugs we are talking about. Granted this is via bugs.sun.com and is a bit of a "one way street" for the open source community, but the content is still valid. Once we have a true open source bugzilla instance working for OpenJDK, the mechanism changes (becoming more open of course).
In the current bug tracking system you see via bugs.sun.com we are using has a category ("java" in my examples) a subcategory ("build" in my example), and I'm using the bugStatus selection which is a number between 1 and 11.
So here are the JDK Build Change Requests (CRs) (CRs cover both bugs and rfes) for all releases, listed based on the state of the bug:
- Dispatched (Submitted but not officially accepted yet)
- Incomplete (Some kind of missing information)
- Accepted (Someone has at least taken a quick look at it)
- Defer (No work being done on it for some reason, rare state to be in)
- Cause Known (Generally it's understood what the cause is)
- Fix Understood (The necessary fix is understood)
- Fix in Progress (The fix is in progress)
- Fix Available (The fix has been implemented somewhere, access may be limited)
- Fix Failed (The fix does not work, rare state, usually goes back to Fix In Progress)
- Fix Delivered (The fix has been pushed into an official repository forest, official is public for OpenJDK)
- Closed (All activity on this CR has stopped, could be a verified fix, could be closed as not a bug)
The general rules about the bug states have a little flexibility between teams and products, but the above is pretty close for most of them. It's normal that when a bug is Accepted, that it gets an engineer assigned to it, but that is not a hard and fast rule. Also, many bugs reach the "Fix Delivered" state and remain there forever, never being changes to "Closed" as a verified bug, not exactly sure why that happens.