|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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Dec 23 2002 - 22:00:26 EST