Tags: OpenJDK
While getting ready to release the full OpenJDK project (due "in the Spring 2007" as we said at FOSDEM) it's giving us an opportunity to go through the processes and workflows the Java SE team has developed in the 12 or so years this project has existed. Twelve years is a lot of time for an organization to develop processes, gain a lot of experience with those processes, and it is these processes we have used to deliver release after release of the JDK platform.
The processes run the full gamut .. business planning .. architectural review .. conformance review .. release content planning .. etc. The processes have been internal to Sun's Java team, and they dovetail with the JCP processes in interesting ways.
As we move to releasing the full OpenJDK project, we know we want to externalize aspects of some or all of those processes. One of the paradigms we're following is Open By Default, meaning that information or decisions or processes should remain visible to the public unless there's a good reason to keep them private.
Clearly what we have is workflow with a variety of documents that exist at different spots of the organization. For example I've served on the CCC, a committee charged with reviewing all changes to "publicly visible 'interfaces'" to Sun's Java SE implementation. The 'interface's are much more than the "interface" objects, they're the API of any class or package, command line options, protocols we implement, etc etc. An engineer desiring to make a change to an interface submits a document to the CCC describing the review, the document undergoes comments, revisions, and two rounds of voting.
With this blog posting I want to put the question out to y'all .. how do you manage these processes? How would you like to see the OpenJDK project processes be made visible?
For example this might look like a web application where one logs in using their
java.net user ID, and roles and access rights within the web application are governed by their role in the OpenJDK project. Within the web application could be a list of proposed changes, proposed projects, etc. Depending on your role you might be able to submit proposals, review proposals, give comments, edit comments, and vote to accept or reject proposals. And the anonymous users (not logged in) would be able to browse and read some or all of the information.
But rather than build a system from scratch ... surely someone has already scratched this particular itch and has developed a suitable system that we could just adopt.
I think often bug tracking systems are applied to many of the processes. In our existing processes many of them do use the in-house bug tracking system for data storage, but many other processes do not do so.
I've been told that "artifact tracking system"'s are what we should look at. I googled and found a few, such as
Scarab, that certainly have the right featureset. The java-source.net list of issue trackers list several such systems.
A few years ago
Michael Ivey wrote an article about software team processes that's apropos. In the Java SE team we already have his points pretty well covered.
It seems that
RedHat uses Project Tracker (from CollabNet) for their process tracking.
Source:
weblogs.java.net
