Gene Heskett wrote:
> On Thursday 26 April 2007, Rene Herman wrote:
>>On 04/26/2007 09:43 PM, Adrian Bunk wrote:
>>> What exactly is missing that the kernel Bugzilla doesn't already offer?
>>
>>Users?
>
> That is the best answer of all, and I've stated my objections to that very
> nearly worthless utility before. And that is exactly why it doesn't
> have "Users". I have never, ever gone to bugzilla without killing well over
> an hour convincing it that yes, I really want DO to enter a bug report, not
> search for an old one. Let me simply say that such and such doesn't work,
> attach the dmesg (or whatever) snip to show how it failed, and get on with
> it.
[...]
Of course it is polite (and more or less expected from reporters,
independently of whether bugzilla or a mailinglist or personal e-mail is
used for a report) to search for similar reports and join them.
However, it doesn't stop there --- a bugzilla entry into which a lot of
different bugs are entered (because the reporters mistook them for the
same or didn't realize they face a number of separate problems) becomes
hard to handle for maintainers/ developers.
So, it is actually easier after all to have users create *duplicate*
bugs and then simply mark them as such once identified. Bugzilla
directly supports tracking of duplicates while my mail user agent
doesn't. (Some advanced MUAs might do, by tagging or the like. But
that would only be visible to myself.)
As subsystem maintainer, I am actively using kernel.org's bugzilla and I
am polling more or less (mostly: /less/) frequently some distributor
bugzillas. Here are my experiences:
- I can't work without kernel.org's bugzilla simply because the
average bug fixing rate of "my" subsystem is so slow. I personally
need a tracker better than some yellow sticky notes or whatever, and
I chose kernel.org's bugzilla for it.
That's one reason why I once and again ask people who report bugs at
the -devel or -user mailinglist to enter their bug into bugzilla.
But often I request this only after an initial conversation with the
reporter, i.e. after the issue was already clarified a bit. Side
effects are that the effort of the user to enter the report becomes
minimal (or even zero if I do it myself instead), and that the new
entry is already rather qualified.
Actually, a good deal of "my" currently unresolved bugs at
bugzilla.kernel.org were entered by myself. Some of those bugs are
behind-the-scene bugs though which only indirectly affect endusers,
thus wouldn't have reported by them anyway.
- Using distributor's bugzillas is a mixed bag. By nature, it takes
more effort for kernel maintainers because linux-kernel is only one
among a huge number of programs tracked in these bugzillas.
There were times were I was able to get a lot of highly useful
reports out of one particular bugzilla; and I name it here because
its admins and users did such a great job IME: Redhat's bugzilla.
Many of the bug entries there were highly focused and qualified and
up-to-date, and some helped to get to bugfixes soon. This positive
experience somewhat diminished lately after the more prominent bugs
were fixed.
At other distributor bugzillas, the usually encountered difficulties
besides the broad scope of their trackers were, in no particular
order:
- Lack of detail in bug descriptions,
- many loosely related or unrelated bugs under the same ticket,
- difficulties to work with the reporters to get more
diagnostics (for varying reasons),
- long delay between upstream release of regressions and
report of regressions by distribution users,
- my lacking polling frequency, being caused by and at the same
time amplifying these other difficulties.
So, bugzilla.kernel.org and to a certain degree distributors' bugzillas
are valuable to me. Still, switching between bugzilla and mailinglist
sometimes becomes awkward, IME in a similar way like switching between
mailinglist and personal e-mail. Also, "my" subsystem (ieee1394) almost
doesn't have to deal anymore with new development, neither on the kernel
side nor as far as available hardware is concerned. Therefore my
findings certainly do not reflect what other subsystem maintainers are
facing.
Back to MODULE_MAINTAINER and what Adrian said about where to report bugs:
>From the maintainer's point of view, my personal preference for bug
reports about "my" subsystem is, in descending order:
- The -devel or -user mailinglist (but often in combination with
bugzilla),
- bugzilla,
- ...?,
- personal e-mail. (Just don't do it.)
But I do understand why the opener of this thread preferred personal
e-mail; he has explained it multiple times now. He has valid points,
although they don't apply to by far most of the kernel subsystems.
--
Stefan Richter
-=====-=-=== -=-- ==-==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
