BugForwardingWorkflow

Summary

We will add reports to Malone showing bugs to be forwarded upstream, bugs that may need to be forwarded upstream, and bugs that have been forwarded upstream to make it easier for bug squads to colloborate on passing bugs upstream.

Rationale

About 50-60% of Ubuntu bug reports are upstream bugs. Malone needs reports that make it easy to see such bugs, while keeping them separate from Ubuntu-specific bugs.

Use Cases

Upstream doesn't use Malone

Assumption: seb128 gets a bug report for gEdit. He confirms it and wants to forward it upstream, because he doesn't have time to fix it.

  • He visits the GNOME Bugzilla to see if the bug has already been reported, finds it hasn't, and reports the bug upstream. He clicks "Link to upstream bug report", enters gEdit, and the bug number he got from Bugzilla and submits the page. A new upstream task is added to the Malone bug report, linked to the upstream Bugzilla report.
  • He does not have time to report the bug upstream himself. He clicks "Link to upstream bug report". He is prompted for the bug number in the upstream Bugzilla, but since he doesn't know it, he just submits the page to add the upstream task. The bug no longer shows up in his bug lists.
  • Same as above, but this time the upstream isn't known. On the "Link to upstream bug report" page seb is presented with just a textbox to enter the product name and a link to the upstream association page for gEdit. He open the upstream association link in a separate tab, enters the product series to associate, saves it, and closes the tab. He enters the product "gEdit" in the Product box on the "Link to upstream bug report" page and submits. He is prompted to enter the GNOME Bugzilla bug number, submits the form, and a new upstream gEdit task is added to the bug.
  • A triager views a bug from her "bugs to forward upstream" report. She searches for the bug in the upstream bug tracker, finds it, and links the Malone bug to the upstream bug report via the "Link to upstream bug" page.

Upstream does use Malone

Jeff, an uploader of the Ubuntu bzr package, is triaging a bug filed on bzr. He determines the bug is upstream. He clicks "Link to upstream bug report" on the bug page. He submits the page, which adds an upstream bzr task, and notifies the upstream bzr contact.

Short-term solutions

Over the next few months, our goals are to:

  • Allow associating bugtrackers with products

  • Implement complete forwarding functionality: http://www.async.com.br/~kiko/mockups/bug-forwarding-workflow.html

  • Create reports showing:
    • Bugs that should be linked to upstream (bugs with statuses for upstreams that don't use malone but have no bugwatches)
    • Bugs that haven't been classified as distro-specific or upstream
    • Bugs linked to upstream
  • Build links between more packages and products by providing a link from the "Link to upstream bug report" page to a page associating the package to an upstream, if the package's upstream is not known
  • Allow upstream maintainers to easily subscribe to all upstream bugs reported in Malone by allowing multiple product bug contacts

Long-term solutions

See the discussion notes.

Unresolved Issues

Who decides whether a bug is in distro or upstream?

How do we handle upstream using a bug tracker that Malone doesn't support? Where upstream doesn't have a bug tracker? Some possible solutions:

  • Add new bug trackers quickly on request.
  • Have a new general bug tracker type, which needs only a URL.
  • Have a new general bug tracker type, but use it only behind the scenes, don't expose it to the user.
  • Use URLs instead of Bugtracker and Remote bug. Debbugs would need some special casing, though.

Also, for our purposes, we want to know which product a sourcepackage is associated with, but the "upstream association" model we have currently has at least two problems, for our use case:

  1. The data gets reset when a new version of Ubuntu is released.
  2. It seems to work with product series when all we need is product.

  • As I said last time this was discussed, there are five use cases for an upstream, not two:

    1. Uses Malone.
    2. Doesn't use Malone. Its bug tracker is registered in Launchpad.
    3. Doesn't use Malone. Its bug tracker could be registered, but isn't.
    4. Doesn't use Malone. Its bug tracker is an unsupported type.
    5. Doesn't use Malone. Doesn't have a bug tracker at all.

    The Malone data model should handle all of them. -- MatthewPaulThomas

BugForwardingWorkflow (last edited 2008-08-06 16:37:55 by localhost)