kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)


[ I removed Frans from cc: since it is off-topic to the original bugreport ]

On Saturday 24 November 2007, Rafael J. Wysocki wrote:
On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
[--snip--]
Rafael, I see that you've filled a bug for this bugreport into kernel
bugzilla tracker (one day after the bugreport):

http://bugzilla.kernel.org/show_bug.cgi?id=9442

Since we try to address regressions with the highest priority in the
IDE-land (and usually they get fixed quickly) I would strongly prefer to
use bugzilla only for long-term bugs and avoid the needless bureaucracy.

As a rule, I put all of the reported regressions into the Bugzilla early. You
are not required to use these entries for tracking the bugs, though. If you

[ I really don't think that the recent push from both Andrew and you in
bugzilla direction is a good thing... ]

There is a mix of technical and psychological issues with using bugzilla:

* Interface for filling bugs is a joke:
- help for "Product" selection is mediocre
("IO/Storage:" -> "Bugs related to IO")
- there is no help for "Componenet" selection
- "Some basic debugging hints" are not there
- "Kernel version" given by reporter should be checked against the latest
kernel version and if not matching there should be a kind request to
retest with the latest kernel
- it should be strongly suggested to attach dmesg output and kernel config
- zillion other little improvements...

[ The average bug quality is not very high (bugs often lack critical
information) and this is really not reporters' fault! The interface
should be kept as simple as possible but if the reporter wants to
find some help and hints they should be there. ]

* Bugs that sit in NEEDINFO state for more than i.e. one month should be
automatically closed.

* After each major kernel release bugzilla should send a kind request for
retesting to all open bugs.

* You can't close/reject bugs by email.

* There is "Assigned-to:" field which is described as "This is the person in
charge of resolving the bug." in bugzilla's help so people get assumptions
that there is somebody who is supposed to handle the bug and that this
person should be actively working on it. Both assumptions may be invalid
(orhpaned drivers, there are more high priority bugs etc.). OTOH mailing
list doesn't give such assumptions and encourages more active attitudes
of bugreporters.

[ also compare this with "Maintained" definition in MAINTAINERS file ]

* From maintainer/developer POV you really want to track bugs in public
(mailing list) so other people can jump in and help.

[ It is also important that the other developers see that you are active. ]

* We want bug tracking the other way around: everything goes through mailing
list first (including bugs filled to the bug tracker) and if not fixed
quickly, somebody (maintainer of the given part of code or a higher level
maintainer) replies cc:ing bugzilla so the new bug entry is added.

Also this way we fix trivial/easy/medium bugs ASAP or reject invalid ones
without any bugzilla overhead. We also add a new patch description tags:
- "Fixes-bug:" tag with reference to the original discussion
and
- "Fixes-commit:" tag with reference to the kernel commit
which are automatically snooped by bugzilla from git so we keep info about
fixed bugs/regression for statistics, bugs history and to aid -stable team
in their efforts.

[ This is just a blurry sketch of the desired workflow but please note how
this is different from just assigning your component to the mailing list
address which should already be possible. ]

* Last but not least our bugzilla just looks ugly (it is _very_ important,
I feel disgusted each time I have to work with it, OTOH I love using
gitweb - you get the idea).

Sigh, I've just realized that comparing to source code control we are in
the "stone-age" when it comes to bug tracking. Hmm, what about switching
to some proprietary bug tracking system just to talk Linus into writing
a superior one? ;-)

don't want to, just leave the entry as is and I'll close it when the fix is in
the Linus' tree.

Therefore I kindly ask you to defer filling bugs for new bugreports for
a week or two, and give us some time to react (and always ping me about
the bugreport status before filling bugzilla entry).

Well, I thought you'd get an email from the Bugzilla, but of course I can notify
you directly about reported regressions related to IDE.

I do get mails from bugzilla so if you are going to assign these bugs to
yourself and track them, then no need to notify me.

[ I also regularly read your regressions list. ]

The alternative solution would be that you fill all new bugreports but
then please assign them to yourself and track their status (if after two
weeks the problem is not fixed feel free to reassign bug to me).

I can do that, but please note that the bugs filed against IDE are assigned to
you automatically, so I'll have to reassign them to me (as I've just done with

Thank you.

this particular entry). If you don't want them to be assigned to you at all,
please contact the Bugzilla administrators and ask them to change that.

Well, I consider this from time to time...

Bart
-
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

  • Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
    ... use bugzilla only for long-term bugs and avoid the needless bureaucracy. ... It looks like you'd like the reporter to initially debug the issue for you ... the bugreport status before filling bugzilla entry). ...
    (Linux-Kernel)
  • Re: Linux 2.6.21
    ... Apparently, unless Adrian posts his ... bugzilla or collect them into one of the a kernel.org's wiki, ... to follow the current state of all the "important" regressions. ... have some human who tries to find messages on the kernel mailing list too, ...
    (Linux-Kernel)
  • Re: Who wants to maintain KR list for stable releases? (was Re: nmi_watchdog=2 regression in 2.6.21)
    ... but some of them are categorized as bugs from the reporter's ... Tracking feature or implementation suggestions wouldn't make sense. ... write what they think the kernel should do but who never write a single ... I am going to look into the bugzilla software to start with, ...
    (Linux-Kernel)
  • Re: Linux 2.6.21
    ... Kernel bugzilla has 1600 open bugs BECAUSE IT SUCKS. ... how do you suggest to track bugs in a way that doesn't suck? ... For getting regressions reasonably grouped for my regression emails, ... debugged by a kernel developer knowing the subsystem in question. ...
    (Linux-Kernel)
  • 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)
Quantcast