Messages in this thread | | | Subject | Re: Dedicated kernel bug database | From | Nicolas Mailhot <> | Date | 20 Dec 2002 12:18:50 +0100 |
| |
|John Bradford wrote: | |> [snip] |> |>Interesting - so the first stage in reporting a bug would be to select |>the latest 2.4 and 2.5 kernels that you've noticed it in, and get a |>list of known bugs fixed in those versions. Also, if you'd selected |>the maintainer, (from an automatically generated list from the |>MAINTAINERS file), it could just search *their* changes in the changelog. |> |It's often difficult to pick a maintainer for a bug - it may not be the |fault of a single subsystem. As an example, I recently had a problem |getting USB and network to function (on kernels 2.5.5x). I noticed that |toggling Local APIC would also toggle which of the two devices worked. | Disabling ACPI allows both deviecs to function regardless of local APIC. | |So, where is the problem? |1) Network driver? It doesn't work with ACPI and both Local APIC and |IO-APIC. |2) USB driver? It doesn't work with ACPI and no UP APIC. |3) APIC? Causes weird problems with various drivers when ACPI is turned on. |4) ACPI? Causes weird problems with various drivers when APIC is toggled. | |(this exact bug was in Bugzilla, though I hadn't checked there before |mailing lkml ;)
I assume you're talking about : http://bugzilla.kernel.org/show_bug.cgi?id=10
As the reporter, I'll tell you plainly bugzilla rocks for this.
This bug was first reported in linux-kernel, then was picked in the 2.5 problem reports, then (when bugzilla.kernel.org) was announced reported again in bugzilla.
Bugzilla enabled the report to be ping-ponged among maintainers until someone accepted it. And it can be found by other people now (note you missed the linux kernel report when you posted this). No one was interested before the bugzilla report.
Bugzilla can be a pain sometimes, it's not intuitive, it's suffering yet from its hackish bastard origin, but it works, lots of projects are using it (both because its so easy to deploy and people are familiar with it - try rt I-need-30+-perl-packages-to-work-only-I-use hell for example) and it's improving.
2.17.1 (seen both at http://bugzilla.mozilla.org/ and http://bugzilla.redhat.com/) is a *huge* improvement, I can't wait for it to be released for everyone (right now the bugzilla team has a hard time integrating all the features everyone and his dog have been contributing back to the project lately).
All bugzilla's I've seen so far would benefit from better version tracking. All bugzilla's I've seen so far would benefit from better UI.
The problems raised in this thread are pretty generic. They should be tackled a generic way in the original project.
However I wouldn't even touch any other bug reporting system. Others (like rt) boast a better original design ; the truth is they have their own warts but not a community the size of bugzilla to find/fix them (and I'm not even talking about security audits).
Once you've grokked bugzilla (which I freely admit is long and painful) you'll find it's actually rather powerful and you'll be trained to interact with : - mozilla bugzilla - kernel bugzilla - apache bugzilla - gnome bugzilla - kde bugzilla - abiword bugzilla - red hat bugzilla
and so on (and all of these deployments have useful tweaks that trickle back in the original bugzilla)
Not having to learn a new UI to report a bug in another project is quite nice. I know I'd have thought twice about the feedback I've given to various organizations otherwise.
Regards,
-- Nicolas Mailhot Not linux-kernel subscribed, sometimes reading the archives, sometimes not [unhandled content-type:application/pgp-signature] | |