Process tracking in the OpenJDK project, looking at Scarab

; Date: Mon Mar 26 2007

Tags: OpenJDK

Last week I posted about (web.archive.org) some thinking we're doing about exposing Java SE team processes to the public and wondering what, if any, tools exist to help do this. Essentially the Java SE team has 12+ years experience with the processes we've developed to manage JDK development as a commercial project. We have several committees and levels of decision making including both technical and business oriented decisioning.

For the purpose of moving to an open by default model we're thinking about exporting these processes to be visible to the world. That's where software tools come into play, as it would be very helpful if there was some software package we could just deploy and use.

I did some searching for "artifact tracking system" and one project, (web.archive.org) Scarab, quickly looked like a very comprehensive tool. I just spent a bit of time reading the documentation and thought to write up some observations.

They variously call this an issue or bug tracking system. Scarab allows for several kinds of "artifacts" (e.g. "Defect", "Enhancement", "Requirement", etc) with several kinds of "attributes" (e.g. "Operating System", "Status", "Priority", etc) so I suppose the model is that someone enters an artifact of whatever kind into the system, and it has a lifetime based on the workflow defined in the system. It probably looks like a bug report but the various sorts of artifacts probably mean for a bit more flexibility.

But this raises a couple questions for me ...

We have an existing bug database for the bugs and it's not entirely clear how we're going to export that database. The interface at bugs.sun.com leaves a lot to be desired, to put it mildly. I'd posted some (web.archive.org) thoughts and queries on bug tracking last fall and it's a complex issue that touches a lot of software teams at Sun, since we're all in the process of moving to open source. It's unclear whether we'd want to use Scarab as the method of integrating our internal bug database with an external interface.

Another question is that not every process is modeled very well as a bug. I know many of our processes today are not in the form that is an issue/bug report in a bug tracking system. But I don't know whether that's due to limitations of Sun's internal bug tracking system.

Source: (web.archive.org) weblogs.java.net

About the Author(s)

(davidherron.com) David Herron : David Herron is a writer and software engineer focusing on the wise use of technology. He is especially interested in clean energy technologies like solar power, wind power, and electric cars. David worked for nearly 30 years in Silicon Valley on software ranging from electronic mail systems, to video streaming, to the Java programming language, and has published several books on Node.js programming and electric vehicles.