[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.98.0704281645100.9964@woody.linux-foundation.org>
Date: Sat, 28 Apr 2007 16:58:23 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Adrian Bunk <bunk@...sta.de>
cc: Diego Calleja <diegocg@...il.com>,
Chuck Ebbert <cebbert@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.21
On Sun, 29 Apr 2007, Adrian Bunk wrote:
>
> Bugzilla has an email interface.
> Andrew forwards bugs from Bugzilla to developers.
Yes. And if you search around, you'll even see that I occasionally use it.
But it's useful only once the bug has been assigned and somebody has
actually *looked* at it. The fact that some people do this is a big credit
(Andrew, Dave J etc)
> There might be small room for improvements, but I don't see how
> man-power or technology could make a big difference in this area.
I'm talking about getting the developers to _look_ at the bugs in the
first place. Bugzilla is not very good at that, because it has no useful
interfaces for doing so (unless you can specify your area of interest so
exactly that you can actually set yourself up as a maintainer of one
particular area).
Almost none of the subtle (and thus harder) bugs tend to fall into that
kind of nice category.
For example, look at suspend/resume bugs. Do you realize that 99% of them
are device driver issues, but how the heck do you connect a "my laptop
does't resume" to the _right_ device driver maintainer?
And do you realize (and acknowledge) that it would be total madness to
send all suspend/resume bugs to _everybody_ who maintains any device
driver at all?
See? THAT is the problem with bugzilla. It only works for the "easy"
cases. It works for the case where a reporter can say with certainty that
the reason his machine doesn't boot is a particular network device driver
(like the sis900 regression we had in 2.6.21). But once you know the
subarea that precisely, bugzilla doesn't even help you that much, and it's
likely easier and more productive to just send email directly to the right
person and cc Jeff and netdev or something!
> "*once* you've found and gotten the right developer involved" is the
> real problem, not how to track bugs.
And I agree 100%.
And bugzilla does *nothing* here.
> *This* is *the* problem.
> And no change in bug tracking will help with this problem.
So why are you pushing bugzilla?
There are actually better bug trackers around. One of them is "google".
For oopses, one of the thngs I do is to put in the most relevant
information (backtrace etc) into google, and ask google to try to find the
pattern. That sometimes actually does pretty well - you can get a real
feel for "oh, there's a pattern here - they're all AMD machines with the
NVidia chipset" kind of thing.
Bugzilla doesn't offer anything even remotely as useful.
It's the "big picture" that tends to be hard to find.
And that's what *you* gave with the regression report. A summary. You even
noted some of the patterns, so people actually had them already somewhat
pre-sorted.
THAT is what we want.
But another way to get the "high-level picture" is to actually just say
"what's active now". And that's why I think the whole "1600 open
bug-reports" kind of thing is useless. Bugzilla does *not* have mail
interfaces for that kind of "these 50 bugs were actively reported on and
unresolved" in the last week summaries!
(And if it did, it would still almost certainly need some human care and
understanding)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists