Kernel space: Are Linux developers ignoring bug reports?

Linux developers seem to be letting bug reports slip throught the cracks. With 1500 open kernel bugs in the tracking system, and 50 going unanswered on the mailing list, do developers need a better process or just new priorities?

By Jonathan Corbet, LinuxWorld.com, 09/12/07

Page 2 of 3

Dave Jones reiterated his statement that developers are not responding to bug reports. We are, as a result, losing bug reporters. Andrew brought up the old idea of doing an occasional bugfix-only release. Such a release would not just avoid the addition of new features; developers would be expected to spend time actively fixing bugs. Perhaps this would send a message that the developers have gotten serious about bug fixing and would inspire long-frustrated users to start reporting bugs again.

Story tools

Sponsored by:

E-Mail article
Print article
Contact author
AIM article	del.icio.us
Reddit	Digg
Stumble	Slashdot It!

Ted Ts'o said that once upon a time, ten years ago, we cared about our bug-free kernel and would help users with problems. It is kind of sad that we no longer have that attitude. In response it was pointed out that the volume of users (and their bug reports) has increased greatly, and that the level of technical knowledge held by our users is now much lower. As Alan Cox put it, ten years ago every user had a screwdriver and most of them did not have the case on their computer.

Alan also claimed that the larger number of users could also be helpful in finding bugs, but that we are not making use of their reports. With adequate information and a bit of statistics, it could become much easier to identify combinations of hardware that lead to problems. To that end, better bug reporting tools would be most helpful. And, in particular, having a single tool (or at least a tool by a single name) supported by all distributors would be a good thing. If developers could ask users to run this tool to generate a comprehensive picture of the afflicted system, they would be better positioned to track down the problems.

Andrew's response is that the discussion had taken a wrong turn. There is no point, he says, in having better tools if developers cannot be bothered to respond to bugs in the first place. He then moved on to the review problem. Code review, he says, has a large multiplier effect. One hour of serious code review can help to get a 100-hour patch into the kernel, and it can help developers to make better patches in the future. But we suffer from a shortage of reviewers.