lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ