OpenJDK Bug Tracking Project
Dr Andrew John Hughes
gnu_andrew at member.fsf.org
Wed Mar 16 08:57:32 PDT 2011
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:
> Thanks Roger. Here are some comments, and some additional suggested
>> * 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
>> - 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.
>> - 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 .
> - 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
>  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.
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
More information about the web-discuss