Kernel regression tracking, part 1

We quite often find kernel bugs when working on rr. For severe bugs, especially regressions, we post to LKML and address specific maintainers because it's the only way to get a timely response (although not guaranteed). Less severe bugs go to Bugzilla because it doesn't seem like a good idea to spam specific maintainers with such bugs. As this article says, a message sent to LKML without addressing specific individuals will be forever lost in the noise. It seems that the Bugzilla bugs are only rarely looked at, though, so we file them more because it's the right thing to do than because we need action.

Requiring bug reporters to directly email maintainers about specific bugs seems really bad for everyone. It makes the bar for reporting bugs very high, since you need to track down the right maintainers, which is practically impossible for end users, and if you guess wrong then your bug is likely to be ignored. I assume it also sucks for maintainers, since it must be difficult to share the workload between maintainers or if the maintainers change, plus every maintainer has to implement their own issue tracking in their email client.

It's amazing how far Linux has come with such immature development practices across the board. This nonsense is tolerated because Linux is so successful, but in a less successful project it would be scorned. If a serious alternative open-source kernel ever arises with more rational development practices and takes share from Linux, people will look back and say "how did they ever think developing *that* way was a good idea?"