Re: MODULE_MAINTAINER

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Bugzilla and management thereof
    ... reporting it to bugzilla. ... the report could be updated to note that it still applies to f7. ... auto-closes bugs from older releases*. ... I was assuming that if Ray decided it was an upstream bug he'd ...
    (Fedora)
  • Re: FC6 through the rear view mirror
    ... package maintainers use bugzilla as a guide for things that need to be ... maintainers to the bug reporters because they haven't fixed the bugs ... report them here even though few of the package maintainers monitor this ...
    (Fedora)
  • Re: FC6 through the rear view mirror
    ... maintainers to the bug reporters because they haven't fixed the bugs ... that you reported (though a search for your e-mail address in bugzilla ... report them here even though few of the package maintainers monitor ...
    (Fedora)
  • Re: Linux 2.6.21
    ... and it's an _advantage_ of the kernel Bugzilla to see more ... than 1600 open bugs because this tells how bad we are at handling bugs. ... Don't say that "bugzilla tells how bad we are at handling bugs". ... there's nothing more frustrating then spending a good chunk of time trying to find a similar bug, then jumping through all the bugzilla hoops to file a report to eventually get a message 'closed becouse it's a duplicate report), then have to go and track down what it's a duplicate of, read through that bug report, only to find that it's not solved there either, and to top it off, the people working on that bug won't see my report or that I'm available to troubleshoot it. ...
    (Linux-Kernel)
  • Re: Linux 2.6.21
    ... bugzilla is a very good tool. ... If I see that someone reports bugs which doesn't really address my ... he's not looking at a single file, he may be maintaining a huge subsystem ... Many people who consider themself as maintainer of a subsystem are ...
    (Linux-Kernel)