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 3 of 3

One problem is that code can quickly disappear into git repositories, from which it speeds into the mainline without much (or any) review. In response to previous pleas, developers have been posting code to the mailing lists more often, but these postings are often late, just before the code heads toward the mainline. Quite a bit of code is going into subsystem trees during the merge window, ensuring that the review period is quite brief. In response it was stated that subsystem maintainers should not accept patches during the merge window. Some maintainers already enforce such a policy, but others do not.

Story tools

Sponsored by:

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

One idea which was discussed was the creation of a pre-merge tree which contains all of the patches expected to go in during the next merge window. It would be much like -mm, but with the full set of queued patches and nothing which is not planned for the next merge window. Andrew claimed, once again, that the wrong problem was being discussed. Why talk about getting more patches posted when the patches which are sent out now are not being reviewed?

Andrew's proposal is that patches, to be accepted in the mainline, must carry a new Reviewed-by: tag identifying who has looked them over. The patch information should also include information like pointers to the discussions with the reviewer so that the depth of the review can be judged; a Reviewed-by tag from a reviewer who is mostly concerned with white space might not have a whole lot of value. If nobody reviews patches, the system will clog up until developers have to do some reviewing just to get things moving again.

The idea was well received, though Linus expressed a concern that most patches, being in general quite small, will never really get serious review. A patch which looks trivial is hard to give a lot of attention to. But some of those patches will certainly carry bugs. So stronger review requirements will, in a world inhabited by humans, still not succeed in catching all of the silly problems. This point was generally understood, but there is still interest in trying out this system in an informal way. So expect to start seeing Reviewed-by tags on patches before too long.