OpenJDK Bug Tracking Project

[mark.reinhold at oracle.com]

2011/3/3 14:03 -0800, roger.lewis at oracle.com:
> 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

Thanks Roger.  Here are some comments, and some additional suggested
requirements.

> * Web Services or REST APIs for querying and updating bugs

Mark Wielaard asked whether the WS/REST API should support creating new
bugs.  I'd go further and say that it should support every operation
that's supported by the system's usual user interfaces.  It should be
possible, in principle, to create an alternative UI that can completely
replace the system's native UI.  This ensures maximum flexibility for
related programmatic systems ("boundary systems"), prevents us from
being locked-in to a (potentially) stale UI, and allows for creative
experimentation with alternative UIs (e.g., based upon Java FX).

I also think we should have a strong preference for REST over WS-style
web APIs.  The big WS-* standards failed.  Let's avoid them.

> * Supports a rich query language
> * Web client
> * Email notification for new bugs
> * Email notification for bug state changes

E-mail notification for content updates (e.g., new comments or updated
evaluations) should also be supported.

I agree with Mark Wielaard that it would be nice if bugs could be updated
via e-mail, but I worry about the problem of authenticating such updates.

> * 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

As we've discussed in person, it's not clear to me that voting by
arbitrary users is something that needs to be supported natively.  If
we're going to continue the Bug Parade voting tradition then that could
be implemented in a separate boundary system.

As to some of Mark Wielaard's other suggestions:

2011/3/4 10:38 -0800, Mark Wielaard <mark at klomp.org>:
> Nice to have things might be:
> 
> - Version tracking of issues, related to openjdk releases/branches.
>   - Known working/failing versions.
>   - Milestones?
> - Attaching files, patches, etc.

This is absolutely critical.

> - 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.

That'd be nice, but I don't know of any system that actually implements
this.

> - 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.

I think this is critical, not only for feature-tracking bugs but also for
distinct, interdependent bugs.  It always annoyed me that Sun's internal
bug trackers never supported dependences.  Ideally one should be able to
express such dependences from either direction, i.e., "this bug blocks
that one", or "that bug blogs this one".

>   - 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.

Yep.

> - 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.

All of these would be nice to have, but I don't see them as critical.

Here a few additional requirements which I haven't yet seen anyone raise.
Some of these are taken or adapted from the OpenSolaris bug-tracking
requirements document [1].

  - Integration with the OpenJDK people database.  The bug tracker should
    provide a programmatic interface for adding and modifying users, so
    that when a contributor is added to the OpenJDK people database the
    system can automatically grant appropriate rights in the bug tracker,
    creating a new bug-tracker account if necessary or tying to an
    existing account.  The bug tracker must also support whatever
    single-sign-on solution is eventually implemented for OpenJDK.

  - It must be possible to hide certain classes of bugs (e.g., security
    bugs) from all but a select few users or groups of users.

  - Extensibility via programmatic state-change hooks or a similar
    mechanism is highly desirable.  Ideally such hooks should be able to
    veto state changes.  Many of the boundary-system hacks we've built
    over the years against Sun's internal bug trackers solved problems
    that could've been more easily solved with such hooks.

  - A stable export format for bug reports (e.g., XML using a defined DTD
    or schema), for easy digestion and repurposing by boundary systems.

  - Both hierarchical (product/category/subcategory) and non-hierarchical
    (i.e., keyword or tag) bug classification.

  - Unicode should be fully supported in all fields of a bug report, in
    the query language/interface, and in the WS/REST API.

Finally, I'm surprised that no one has mentioned the "CR/sub-CR" feature
of Sun's current internal system.  It's a bit clunky, but it makes it
relatively straightforward to track related-but-distinct fixes to the
same bug in different lines of code.

- Mark


[1] http://src.opensolaris.org/source/xref/website/spec/dts-requirements/d-dts-requirements.txt