OpenJDK Bug Tracking Project

[Dr Andrew John Hughes]

On 16 March 2011 04:59,  <mark.reinhold at oracle.com> wrote:
> 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
>

You seem to have omitted the licensing of the bug system.  It should
be Free Software, in line with the rest of OpenJDK.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37