A thread on the Linux Kernel mailing list discussed the process in place for reporting, bisecting and fixing bugs. In response to a suggestion that some of the issues could be solved by introducing new procedures, Al Viro retorted, "we've got ourselves a developing beaurocracy. As in 'more and more ways of generating activity without doing anything even remotely useful'. Complete with tendency to operate in the ways that make sense only to bureaucracy in question and an ever-growing set of bylaws..." Later in the thread, David Miller agreed and noted that ,"the resulting 'bureaucracy' or whatever you want to call it is perceived to undercut the very thing that makes the Linux kernel fun to work on. It's still largely free form, loose, and flexible. And that's a notable accomplishment considering how much things have changed. That feeling is why I got involved in the first place, and I know it's what gets other new people in and addicted too."

Andrew Morton tried to return the discussion to its original topic, "the problem we're discussing here is the apparently-large number of bugs which are in the kernel, the apparently-large number of new bugs which we're adding to the kernel, and our apparent tardiness in addressing them." Al noted that some of the problem is that git is so efficient at merging code, "the patches going in during a merge (especially for a tree that collects from secondaries) are not visible enough. And it's too late at that point, since one has to do something monumentally ugly to get Linus revert a large merge. On the scale of Great IDE Mess in 2.5..." Another suggestion was made to replace bugzilla with something better, to which Andrew replied, "swapping out bugzilla for something else wouldn't help. We'd end up with lots of people ignoring a good bug tracking system just like they were ignoring a bad one."

"The http://www.kerneloops.org website collects kernel oops and warning reports from various mailing lists and bugzillas," noted Arjan van de Ven, announcing the new website. He included a summary of the top 10 oopses collected in the past 7 days noting, "this is the first such report that I'm posting; Please let me know if this is useful or not."

Feedback was positive. Andrew Morton commented, "well that would have been fun to write." Steven Richter expressed some concern about the tool counting the same bug report duplicate times when found in different places. Arjan aggreed, "this is true however it's .. a hard issue. It's really hard to distinguish a duplicate report from two reports of the same bug." Another concern was in separating oops generated by 2.6.X-rcY kernels from 2.6.X-rcY-mmZ kernels. Arjan noted, "finding what exact kernel version an oops is from is... surprisingly hard. And to be honest, bugs against -mm are still very interesting, since they'll be the next mainline after all".

Adrian Bunk posted a couple lists of known regressions that found their way into the 2.6.21-rc1 kernel [story] since the release of the 2.6.20 kernel [story]. Adrian notes that his lists only include bugs that are not yet fixed in Linus' -git tree. In an updated version of his lists he included 19 known regressions, including links to bugzilla or the appropriate mailing list discussion thread. The lists track who submitted the bug, who is currently handling it, who caused it if known, a link to a patch that fixes the problem if any, and the current status.