Tags: OpenJDK
Hi all, as we're getting ready to start launching the open sourced JDK project we have a number of questions that are being pondered. The question at the top of my mind today is the bug tracking system. I would like to open up some discussion with you people as to what you find useful in a public bug tracking system.
One of the things I found is this book:
Producing Open Source Software which is a pretty comprehensive overview of open source software processes. There's a chapter on bug management systems, and an appendix on
Free bug tracking systems. These provide some great information.
I used the phrase "public bug tracking systems" purposely. At Sun we have an internal bug tracking system that's used for all of the company products, including Sun's Java. It's a private system, but the
Bug Parade externalizes the bugs. Hence my distinction between an internal bug tracking system like the one Sun uses, and one we could use in the public for tracking bugs in the open sourced Java project.
Do the requirements really differ between a private or public bug tracking system?
How much of the bugs kept in the private bug system should we export to the public bug system?
An idea I picked up from the Producing Open Source Software book suggested that bug reports shouldn't be conversational. Bug reports do have a conversation of sorts, but with a specific purpose. That is to record data about the bug, and reporting status on fixing the bug. The submitter and the development team, ideally, will have a conversation about clarifying the bug report and moving to a solution. That's the conversation the bug management system should emphasize.
Another idea is about handling the emails which notify interested parties of events related the bugs. This is an area Sun's internal bug handling system where I think it's pretty good. First, people can subscribe to specific "category", and they'll receive an email on any bug related to that category. Second the bug submittor also receives notification emails. Finally, anybody can subscribe to a specific bug and receive notification emails. It works pretty good, but I don't know which of the public bug management systems offer that flexibility.
I'm curious about the role of moderating comments to a bug. I'd expect that a public bug tracking system will see some version of comment SPAM or sometimes flame wars will erupt over divisive bugs. All other public web sites I've seen that allow public comments endure some form of these. And the solution is often to have humans tracking the web site and deleting innapropriate comments. Is this also true for bug tracking systems?
And there's the issue of bug triage. In the Producing Open Source Software book this is called Pre-Filtering the Bug Tracker. At Sun we handle this through having a dedicated team screening the incoming bugs. They see many duplicates or incomplete bugs and work with the submittors to improve the bug quality before submitting it to the regular bug system. This takes a lot of effort, but is helpful.
I think an interesting opportunity is being missed by this. Given the number of duplicate bug submissions it suggests that the previous bug submissions could form the basis of a knowledge base on correct API usage, best practices or known workarounds. So I'm curious if any of the bug management systems can serve that role as well?
In particular the Trac system seems like it ought be able to work as a knowledge-base. That system is wiki-like in that you can use Wiki-style syntax (such as CamelCase) to autocreate interesting links and pages.
Are the searching capabilities on any of them good enough so users can readily find duplicates just with a search?
So that's all I want to write on this. Please let me know your thoughts, and I will take them to the team in charge of making the decision for bug management systems.
Source:
weblogs.java.net
