OpenJDK Bug Tracking Project
mark at klomp.org
Fri Mar 4 10:38:29 PST 2011
On Thu, March 3, 2011 23:03, Roger Lewis wrote:
> A draft of the OpenJDK Bug Tracking Project is now available. For
> further information please see:
It might be easier to have these requirements just posted to the
list for discussion. Here are the requirements listed so far:
Below are high-level requirements that have been collected:
> * Web Services or REST APIs for querying and updating bugs
And I assume creating?
> * Supports a rich query language
> * Web client
> * Email notification for new bugs
> * Email notification for bug state changes
RSS feed for bugs based on query?
Some way to create/share "pre-canned" queries of bugs?
Would be nice if email can also be used for adding comments, etc.
Public autobuilders could send an email or do a update of a bug when a
build with a patch referencing a bug is successful (or failed).
> * Able to look up old bug Ids
> * Available 24 hours a day, 7 days a week (not including maintenance
> * Provides the ability to vote and comment on a bug
Why would you voting? And what kind of voting do you have in mind?
> * User role will define what access user has to data Role Types:
> 1. View Bugs (by far the largest group): Anyone in the world with a web
And through the mailinglist and rss feeds I hope?
> 2. Vote, watch, add comments, submit bugs: End users, Java Developers,
Is there really a difference between these groups of users?
> 3. Update bugs: Java Developers who submitted the bug, OpenJDK developers
> 4. Ownership of bugs: Open JDK Developers
How do you define "Ownership"?
> 6. Create/Change categories, manage users, manage data , Admins
What are the requirements for the categories?
Do you expect some correlation between categories and users groups?
> * All JDK bugs (open and closed) will be migrated to the new system.
This includes bugs back to version 1.0
That would be nice, but it might be a lot of work and constrain how
new bugs get added. Maybe these could all be "archived" bugs, that
you could lookup, but not change anymore.
Hopefully this also means we finally get all bugs public and that
bugs are not made inaccessible to some people as is currently the
case on bugs.sun.com (so frustrating...)
> * Must be able to support large volumes of bugs up to 1M bugs (plan
for 10+ years). The current JDK tracking system has about 120,000
Nice to have things might be:
- Version tracking of issues, related to openjdk releases/branches.
- Known working/failing versions.
- Attaching files, patches, etc.
- Inter bug tracking (so you can reference bugs from other project,
downstream/upstream, etc.), with possible notification when such
a referenced bug gets updated and/or updating other bug trackers
when this bug report gets updated.
- dependencies between bugs, so you can create tracking bugs for
some feature, which is only completed when all bugs that it
depend on are resolved.
- Bonus points for having nice dependency graphs.
- mercurial integration, so that when a patch that references a
bug is committed to some tree it can add a note to the bug report.
- bug group category or user watching, so one can follow work
(useful when you take over someone work for a while, or need to
do Q/A for some category of bugs).
- have some way to mark/show frequently occurring bugs, so you
can easily reference known issues with a simple URL.
- integration with patch viewer/review process/mercurial
so patches attached to bugs can easily be reviewed, changed
More information about the web-discuss