https://bugzilla.kernel.org/show_bug.cgi?id=89511 --- Comment #76 from Theodore Tso (tytso@xxxxxxx) --- The problem is that there way too many users for kernel developers to support. There are companies who specialize in getting vague reports for problems on stable kernels (as opposed to the latest development kernels), from users who don't know how to create a reproducible test case, or how to give a concise bug report that has all of the necessary information in one place. (Or for that matter, understand how to use bugzilla properly!) If someone wants to join the kernel mailing lists, and actively work the problem, and submit patches, the upstream kernel devs are happy to invest effort in helping someone learn how to participate in upstream kernel development. The model though of a kernel developers grooming bug tracking systems for help requests, and trying to get enough information to identify a problem, and then making it the kernel developers' responsibility to track whether or not a user's issue has been resolved, simply doesn't scale. There are way too many users, and they outnumber the kernel devs. If we followed that model, we would never get any work done. As far as this specific issue is concerned, it seems that per-USB-major/minor blacklists are the best way to go. Trying to add block layer and file system level workarounds for what is, at its core, crappy hardware, doesn't seem to make any sense. The bigger problem is that this web page will be around for all eternity as an attractive nuisance, and clueless users will see something which has similar symptoms, but a completely different cause, and then re-open and demand support. This seems to be an insoluble problem, and I'm not sure what if anything can be to address this. (And to be honest, it's much more of a problem for the Ubuntu Launchpad than the kernel bugzilla.) -- You are receiving this mail because: You are watching the assignee of the bug.
