Tracker vs Bugzilla

This page is about Jonathan Watt's proposal that the SVG WG phase out Tracker in favor of solely using the W3C's public Bugzilla instance for issue/action management.

Aim

To have the SVG WG use a single issue tracker where any interested party can at least view, open and comment on issues (this does not preclude having issues or fields on issue that can only be viewed/edited by members).

Assumptions

This page assumes that Bugzilla and Tracker are the only issue tracking systems on the table, since it's been made clear that the W3C Systems Team is not going to support anything else due to resource constraints.

It is further assumed that Tracker does not meet the aims outlined above since jwatt's original proposal to allow the public to raise and comment on issues in the SVG WG's tracker was rejected because the W3C's System's Team don't believe home-spun solutions like Tracker get the required security attention to be safe enough to be opened up like that.

That leaves us with Bugzilla, and with figuring out how to make it meet our needs (and desires).

The current situation

Currently, issues that should be getting the attention of the SVG WG are tracked in two different places (three if you include the mailing list, but things tend to get lost/forgotten there). We have a public Bugzilla instance where the public can report and comment on issues that the SVG WG needs to address, plus a semi-public Tracker instance that is writable only by members of the SVG WG.

The WG currently uses the Tracker instance during its own day-to-day work, and so far has done little to encouraged external people to report issues directly to Bugzilla. The reluctance of the WG to encourage use of Bugzilla is understandable since (besides Bugzilla's own shortcomings) having two separate issue tracking systems is a real pain. However, the unfortunate result is that external people are still using the "bad old system" of sending mail to the public list to report spec/test issues, where issues can be forgotten, unsatisfactorily resolved, intermingled with other issues, or spread across multiple separate threads. We should be getting them to use a robust, purpose built system, dammit!

There are several reasons to solely use Bugzilla, including:

• A single system will avoid duplication, save us time, and encourage external people to use it instead of the list.
• Tracker is much less powerful than Bugzilla.

However, the current Tracker system does offer several things that the WG would miss, as discussed below.

Bugzilla's advantages

• Sends out email to reporters and others when issues are officially closed, change state, etc.

Tracker's advantages

• Tracker's interface is a lot less intimidating and ugly, and has far fewer form fields.
• Whenever an issue/action is mentioned on the mailing list, a comment is added to the issue/action linking to the mailing list email.
• Whenever a commit is made in CVS where the commit message mentions an issue/action, a comment is added to the issue/action linking to that commit.
• During IRC minuting the ISSUE/ACTION statements can be used to file issues/actions.
• In IRC using "ACTION-XXX: ..." will append a note to the action.

Improving Bugzilla

While Bugzilla offers many advantages over Tracker, that does not negate the benefits of the current Tracker system. This section discusses the steps we would need to take to bring the same benefits to Bugzilla.

Cleaning up Bugzilla's interface

The current Bugzilla interface (e.g. the page to show/edit an issue, file a new issue or search existing issues) include lots of form fields that are not relevant to the SVG WG or that shouldn't be shown to casual users. There are various alternatives to cleaning up Bugzilla's interface.

Using templates

Seems like the idea to use templates is a dead end. It would be great if it was possible to use Bugzilla templates to provide much cleaner pages. The problem is that we'd want to do this on a per-product basis since each form field is probably used by at least one of the other groups using the W3C's public Bugzilla, making it impossible to remove fields across the entire Bugzilla install. Unfortunately the template system is not designed for per-product or per-component customization. Max Kanat-Alexander (core Bugzilla developer) says it would be easier to hack in a per-product customization for the bug filing form template than other templates, but even for that only light per-product customization would be practical.

Is this really true? Could we not have a custom template that basically just contains "if SVG use svg.tmpl else use default.tmpl"??

There's also the issue of updating templates when the Bugzilla version is updated.

Using wrapper pages

Another alternative is to create a fresh set of webpages that can be used as an alternative interface to Bugzilla (essentially wrapping up Bugzilla behind a nice and simple interface designed just the way we want it). These pages could be put on w3.org or elsewhere.

The Bugzilla WebService API can be used to programmatically interact with Bugzilla via JSON-RPC or XML-RPC. The main hurdle to using this API is that the JSON RPC page on the W3C's Bugzilla and the the XML RPC page on the W3C's Bugzilla have not been enabled.

Of course our wrapper pages could make XMLHttpRequests to the actually Bugzilla pages and parse data out of them, but that would be a lot harder and a lot less robust. It would be better to get the RPC pages enabled.

Following Bugzilla activity

If the idea of moving away from Tracker and solely to Bugzilla is partly that issues reported to the mailing list should be reported directly into Bugzilla instead, then we should have an easy way for people to follow all SVG activity in Bugzilla. (Include automatically seeing new issues as they're filed, just as people can see new threads as they start in the mailing list.)

Actually, we already provide this in a way, since new SVG issues in Bugzilla have their "QA Contact" field set to "www-svg@w3.org" (at least by default) so that all email Bugzilla sends out for these issues is also sent to the public list. If we start to use Bugzilla heavily though, we may wish to stop doing that so that the mailing list doesn't get swamped. We could solve this either by using a separate readonly "SVG bugmail" list, or else by using a bogus address such as "issues@all.svg" in Bugzilla and have people "watch" that themselves (giving them finer grained control over the emails they get). Or both.

Relying on the "QA Contact" field being set to "www-svg@w3.org" in order to watch all SVG activity in Bugzilla isn't ideal, since it can be changed. A more robust mechanism would be product/component watching, but that would require either:

• Mozilla's extension for Bugzilla to enable component watching (unfinished)
• Built-in Bugzilla support for product/component watching (not yet implemented)

Questions

• how can we do "due dates?" in bugzilla?
• Does bugzilla support customizable privileges so that we can add an "svgwg" privilege similar to "editbugs".

How can bugzilla be used to:

• get a list of the issues assigned to a given individual?
• get a list of the issues in a product
• impersonate a user to add comments from a user

Making replies to bugzilla generated email appear as comments on the bug

This is probably not worth pursuing at this time. It's of limited value and there are issues. For example:

• Authentication may require something like signed emails.
• We probably don't want quoting in a reply to be included in the comment that's added to the issue, unless the comments are interleaved with the quoting.
• We probably don't want any signature or legal disclaimer in a reply to be included in the comment that's added to the issue.

Random

Tracker lets you do conolidated actions across all trackers.

When should you use the mailing list, and when should you use the issue tracker? If the a communication to the list requires any action from the WG other than simply replying to that email, then that action should be tracked in the issue tracker to ensure that it is not overlooked or forgotten.