Re: [patch] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"

On Sun, Jan 06, 2008 at 11:36:23AM -0600, James Bottomley wrote:
On Sun, 2008-01-06 at 10:11 -0700, Matthew Wilcox wrote:
If there's willingness to change, I'm willing to put some effort into
moving us to a bug tracking system that fits our workflow better than
bugzilla. But if that effort will be disregarded, then let me know now
so I don't waste my time.

Well, I'd say yes, certainly, and I'll support the effort ... but the
problem is that I'm not one of the powers that be who control our
current bugzilla ... that's the constituency we need to convince. As I
keep saying, just getting new SCSI bug reports tipped onto the SCSI
mailing list will give us about 90% of what we need, but I haven't even
managed to get that to happen.

As long as the process will be that much complicated, it will never
correctly work. The primary requirement for a useful bug reporting
workflow is *not to put the burden on the reporter*.

I agree with Ingo here. How can a user know where to post ? He has
a problem with his Linux distro. He finally understands or gets told
that the strange numbers on the screen indicate a kernel oops and
that he must report it if he wants it to be fixed. He then googles
for how/where to report a bug, and the first reply says :

http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html

in which you can read :

"If you are totally stumped as to whom to send the report, send
it to linux-kernel@xxxxxxxxxxxxxxx".

So *this* is the official central entry point, like it or not. And
in fact it works, given the number of off-topic reports we get. It
proves that end users know how to report their problems there.

Other lists should be used when the problem is clearly qualified.
And most of the time, it's not up to the end user to qualify his
problem, but to *us*. Our mission is not to blindly write lines of
code, but to spend some time getting user feedback, and bug reports
are part of this feedback.

In my opinion, the most important reader contribution to LKML is
just reading bugs reports and redirecting them to the proper list
if obviously required. People do this all the time and it has
always worked.

In parallel, bug entries may be added into bugzilla, either by the
reporter once suggested to do so, or by the person redirecting him
to the proper list.

So a working workflow would look like this :

1) from: user
to: lkml
subject: help needed with my CD burner

2) from: any LKML reader
to: user
cc: lkml, linux-scsi
subject: re: help needed with my CD burner

Message forwarded to linux-scsi. You may accelerate resolution
by describing your problem in bugzilla [url, mail...]

=> user knows his problem is being considered (very important)
=> user is connected with the proper list and possibly with a
bugzilla entry. As long as the bug is not 100% sure relevant
to linux-scsi, lkml should remain CCed so that other readers
may occasionally spot the problem.

I would also like to make a parallel with how support works in
commercial products. Generally, you as the end user don't know
anything about the vendor's internal process. You don't even
know if you have an account on your vendor's support site (another
blocking factor of bugzilla BTW). So what you do is call any of
your contacts overthere, quickly describe your problem, and most
of the time he gives you all the indications required to report
a fine bug. And if he understands it will be too hard for you
(classically because of missing account), he will initiate it
by himself. At this point the bug is tracked and followed by the
appropriate persons.

LKML *is* the contact for any Linux Kernel problem or question.
As long as we will try to bypass it and create parallel ways,
it will only maintain confusion and lead to bugs getting dropped
with user frustration.

IMHO, the only missing indication in "reporting-bugs.html" above
is :

"if you don't get any reply within 2 days, surely your mail
has not been noticed, repost it, if possible with a more
appropriate subject".

We will *never* be able to educate newcomers, but we can (and must)
educate regular readers to help newcomers report bugs. If only 100
regular readers randomly forward 2 mails a month, those are 200 bugs
which get properly handled. Just don't forget to change your reply-to
to lkml if you don't want to get polluted by the discussion.

As to using bugzilla for bug tracking... Well, I agree that bug
tracking is important when you work on multiple problems at once.
But bugzilla should be the developer's tool, not the end user's.
That means that it should only be our job to create entries there
if end users find it too difficult, and that we should just invite
them to *try* to report there to save us some time.

Willy

--
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: Mantis package bombs
    ... for you to report problems in the place that's most accommodating ... things to bugzilla personally. ... implied when I described the bug as "outstanding" rather than "still ... if a bug is likely to be an upstream bug (not ...
    (Fedora)
  • Re: [patch] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"
    ... This bug was actually hidden in bugzilla for ages, ... The bugzilla just tracked a bug reported to lkml. ... "if you have a problem with the Linux kernel, then report it to lkml" ...
    (Linux-Kernel)
  • Re: Linux 2.6.21
    ... you can see the _history_ of each bug report sent to LKML ... I didn't want to say that one could entirely replace a bug-tracking system ...
    (Linux-Kernel)
  • Re: [patch] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"
    ... Noone knows how many thousand bug reports have never reached lkml ... filing or get back to terminate the report. ... But I would like kernel people to become less egocentric ... Send _one_ email to lkml and you'll get forever spam to this address. ...
    (Linux-Kernel)
  • Re: 2.6.25-rc8: FTP transfer errors
    ... Yes, Mark, we used to do things that way for every bug in the kernel. ... We should be very careful about git-bisect. ... the developers, because when they think they might have fixed it, ... But I know that a report is a report, and even if I have a ...
    (Linux-Kernel)