A bug's life
« previous entry | next entry »
Aug. 9th, 2011 | 07:00 am
The JDK 7 Updates Project in OpenJDK is now up and running. We've spent some time in the past couple of weeks discussing processes, finalized them, and started accepting changes destined for JDK 7 Update releases.
Changes going into a JDK 7 Update are typically bug fixes, coming to JDK 7 Updates through JDK 8. Bugs get reported through several channels - for example through Oracle's QA engineers running tests on early access builds, an OpenJDK developer working on some piece of code, or through the web bug report form.
When a Java developer or end user reports a bug through the web bug report form, a process kicks off. All bugs coming in through the web bug report form start with the initial priority 4, i.e. 'Low'. Priorities can go from 5, i.e. 'Very Low' all the way up to 1, i.e. 'Very High'. When you're starting to hack on OpenJDK, it can be easier to do so by picking out a couple of P4, or P5 bugs from the bug database in order to learn how the processes work with some success before you go on to tackle harder tasks.
There is a WebBugs team at Oracle that reviews the incoming bug reports, in order to weed out duplicates, or misfiled issues, and if necessary request additional information from the submitter. Not all bugs are created equal, so the low priority automatically assigned by the system to the incoming bugs sometimes needs to be adjusted, as well.
When adjusting the priority of a bug, we look at three aspects: Impact, Likelihood & Workaround. Impact is determined by taking a look at how severe an issue is: A VM crash would have a high impact, for example. On the other hand, the likelihood of the crash occurring could be very low. And finally, the existence of a workaround, in particular an easily applicable one, would also impact the priority of the bug. A high impact bug that strikes often and has no workaround would accordingly get a higher priority then a 'benign' bug that occurs rarely and has an easily applicable workaround.
The priority is not set in stone - as OpenJDK developers start investigating an issue in order to produce a fix for JDK 8, new information regarding impact, likelihood or workaround can emerge, resulting in an update of the bug's priority. For example, if a bug turns out to have a much higher likelihood to occur then initially thought, that could be a good reason to raise its priority. On the other hand, if e.g. an easily applicable workaround is found, that could be a good reason to lower it.
Another important dimension of a bug, along with its priority, is its state. For bugs in process of being addressed, there are three important states to be familiar with: 'Fix In Progress', 'Fix Available', and 'Fix Delivered'. The first one (obviously) means that a fix is in progress. 'Fix Available' means that a fix has been delivered into an OpenJDK Mercurial forest. Typically, the bug's evaluation in the bug database is updated to include a URL to the commit in OpenJDK, as well - look for the line starting with "http://hg.openjdk.java.net" if you want to see the source code for a specific bug fix. The fix then progresses through a sequence of integrations into the respective Project's master. For JDK 7 Updates that sequence is fairly short, since we only have one integration forest (jdk7u-dev) in OpenJDK. Finally, once a fix appears in a build, its state is set to 'Fix Delivered'.
With these two bits of information, you can follow along your (and other people's) issues progress in JDK 8 and JDK 7 Updates. For some code, like HotSpot fixes, the path can be a bit longer, since the HotSpot team uses the HotSpot Express model to develop stable versions of HotSpot into multiple JDK releases, so the fix first needs to make it into a HotSpot build, before it can get into JDK 7 Updates through a bulk change. As fixes progress through integration stages, our testing machinery is hammering on them to make sure they work well, work well together, and hold up under pressure.
So, thanks for testing JDK 7, and letting us know about the bugs that bug you. With JDK 7 Updates now up and running, you can help us weed regressions out by testing early access builds, and of course by following along on the jdk7u-dev mailing list as fixes are proposed, reviewed and approved for JDK 7 Updates, and reporting issues you find to our bug tracker.
On a side note, we're working on updating our bug tracking infrastructure used in OpenJDK, which should further increase the transparency of both JDK 8 and JDK 7 Update development in the future.