Bug forwarding methodology in Ubuntu (Re: 10k open Ubuntu bugs)

[Matt Zimmerman]

On Mon, Apr 24, 2006 at 05:15:47PM +0100, Sitsofe Wheeler wrote:
> This is interesting. I was chatting with an extremely on the ball Ubuntu
> dev in #launchpad the other day (and in fact someone on #ubuntu-bugs
> earlier today) about stuff like this. I do think that Ubuntu's bugzilla
> is a bit too "friendly" at the moment and is going to be crushed under
> the weight of "fix anything/everything" reports. Perhaps this discussion
> would be better off on one of the launchpad lists though (which still
> aren't on GMANE - http://www.gmane.org/ : )

I've been thinking for a while that we need some documentation in this area,
which explains how bug reports in Ubuntu are handled.  Because some bugs are
specific to Ubuntu, or manifest themselves differently in Ubuntu than
elsewhere, it is appropriate for most user bug reports to be sent to Ubuntu
for initial processing.  However, we obviously don't have the manpower to
fix every bug in every package we ship.

Our goal is to aggregate the best of the open source world, integrate it
into a coherent system, and release it regularly.  Therefore, with our
limited resources, we can only devote specific effort to fixing bugs which
are a) particularly relevant to the Ubuntu project and its goals, b)
specific to the Ubuntu distribution, c) interfere with our goals or schedule
for the current Ubuntu release.

Most of the bug reports we receive do not fall into these categories, and
the correct course of action is:

1. Verify that the bug is not specific to Ubuntu
2. Forward the bug to the upstream project for further processing

This way, we parallize our efforts across the broader open source community,
and draw on the specialized knowledge of our upstream projects.

The desktop team does a fantastic job of coordinating this activity with the
GNOME project, but we draw from thousands of other projects where we do not
have such well-established processes yet.  What we need is a good workflow
for:

- Marking that a bug should be forwarded upstream
- Keeping track of appropriate upstream points of contact for a given
  product
- Actually forwarding the relevant information upstream

This might mean filing a bug in a bug tracker and adding a bug watch (as
with GNOME) or sending an explanatory email to the upstream developer and
recording in Launchpad that the bug has been passed on (we don't have an
established .

The bad news is that, as a manual process, this is very labour-intensive:
finding the correct upstream contact, formulating a proper upstream-oriented
bug report, facilitating communication between the upstream contact and the
user(s) who reported the bug, etc.  Many (most?) upstream bug trackers
require registration for filing bugs or sending/receiving comments,
requiring that either the bug reporter create an account, or the bug
forwarder create an account and shuffle comments back and forth.

The good news is that I think there is hope to automate much of this work
using Launchpad, a possibility I have discussed with the Launchpad
developers at some length.  However, this will take time, especially for
proper integration with upstream bug tracking systems.

Meanwhile, I would like to avoid having these bug reports go unanswered.  To
this end, I propose the creation of a team to do the following:

- Verify whether a bug is Ubuntu-specific (in some cases this will be
  obvious, while in others it will require some analysis, examination of the
  patches in the package, understanding of the program's internals, etc.)

- For bugs which are not Ubuntu-specific, determine the appropriate place to
  report bugs upstream (this information should be retained, perhaps
  initially in a wiki page but hopefully directly in Launchpad soon)

- Forward the bug report upstream with a brief note and some stock text
  which explains that the report was filed in Ubuntu, but applies to the
  vanilla upstream version as well

- Record the fact that the bug report has been passed on (perhaps by
  assigning the task to a "dummy" team created for this purpose), and inform
  the bug submitter (probably with a canned response)

Thoughts?

-- 
 - mdz