Bug Fowarding Workflow (discussion notes)

Summary

The spec aims to improve the workflow of forwarding a bug upstream. Today, a bug is forwarded by first searching the upstream bug tracker for an existing bug, and then, if no bug was found, file a new one. After that it's possible to to link the Ubuntu bug to the upstream bug. This is quite a lot of work, though, and it should be possible to simple mark the bug as being an upstream bug, and then have someone else handle the upstream linkage.

Today's bug forwarding workflow

• If a bug is upstream, we have to find it in the upstream system, and then tie it together.
• Otherwise, file a new bug, and tie it together by hand.
• All of this is done by hand, which takes a lot of time to cross-correlate.

Problems with the current workflow

• Bug triagers have to do things by hand.
• Bug triagers become the single bottleneck for tracking bugs
• Bug reporters aren't the point of contact for upstream bugs
• Upstreams don't use Launchpad, and most of them don't want to

Goals of upstream communication

• Eliminate the middlemen
• Encourage co-operation between projects
• Work is offloaded to people who are best equipped to do it
• Only forward bugs that aren't our fault
• We should not be forwarding feature requests
• Forward bugs that have potential to be resolved. Activity.
• Ubuntu developers file useful reports upstream
• Don't reject bugs, just because they have nothing to do with packaging.

Long-term solutions

• Creating an easy form letter to mail upstream.
  • Create a bug tracker which is "E-mail to this address"
  • Developer can push bug filing upstream through LP.
• Mark that something should go upstream, inside Launchpad
• Convince everyone to use Launchpad, better than Sourceforge.
• Distributed bug tracking network

Short-term solutions

• Reporting inside LP for which bugs haven't been filed upstream
• Package to a bug tracker associations by UI: (When clicking "Upstream", offer links to type in a bug number, open a search in that BTS, or file a new bug in that BTS.)
• Products should allow upstream to trivially add themselves as bug contact, with multiple bug contacts
• Should be easy to tie a bug tracker (real or pseudo) to every product. These can be e-mail or URLs or whatever.
• Follow upstream duplicates to track real progress.