bug tracking

[Andrew Morton <akpm@osdl.org>]

Adrian Bunk <bunk@stusta.de> wrote:
>
> is your problem still present in kernel 2.6.16-rc1?
>

What I've been doing for email bug reports is

a) Respond if I can, forward to maintainer, save them away

b) Wait a while (weeks to months)

c) Privately email the reporter, saying "if this bug is still present in
   2.6.15, please raise a report at bugzilla.kernel.org"


I've sent 100-200 of these emails in the past few days.  Of the people
who've responded, the great majority of these bugs were actually fixed, which
is nice.

My overall intent here is: if the bug isn't quickly resolved, get it moved
from email into bugzilla, where we can sanely keep track of its status.

For long-term bug tracking, I want to only track bugzilla-based bugs.  It
just gets too insane trying to follow the status of email-based reports.


What I'm doing locally is tracking all the bugzilla bugs which I think need
addressing, categorised by subsystem.  Go through them periodically, toss
out the ones which have been fixed.  I have a few hundred reports to go
through and I plan on getting nicely-collated per-subsystem reports out to
the mailing lists soon - probably next week.

I'm not tracking acpi at all - the acpi guys are doing that well and there
are too damn many of them ;)

What I'm not bothering to do is to close off or to reject fixed or
uninteresting bug reports.  I just silently ignore them.  Which means that
a bugzilla-based query will toss up a lot of noise, which is sad.  And I'm
not ensuring that all bugs are categorised as well as they could be - I do
that locally.  It's be nice to do these things, but it's dull and
time-consuming.

I do expect and hope that subsystem maintainers and developers will put
bugs into appropriate states as they work on them - most people are good
about this, but it varies a lot.