OpenJDK Bug Tracking Project

[Mark Wielaard]

Hi Roger,

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:
> http://cr.openjdk.java.net/~rlewis/BugTracking/OpenJDKBugtTracking.html

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
and downtime)
>    * 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
browser

And through the mailinglist and rss feeds I hope?

> 2. Vote, watch, add comments, submit bugs: End users, Java Developers,
OpenJDK 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.
  - Milestones?
- 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
  and/or committed.

Cheers,

Mark