On Fri, 14 Jul 2023 18:59:08 +0100 Mark Brown wrote: > > If we try to fend off anyone who doesn't understand common meaning > > of words the document will be very long and painful to read. > > That's true, but "bug" is one of those things where there is a frequent > disconnect on definitions, and when coupled with the must respond bit I > can see things going wrong. Right, I agree the "what's a bug" arguments often happen but they happen primarily when people are trying to get Greg to pull patches into stable. Or when people try to fast path their "oh, so important feature" into Linus's tree skipping -next. The simple way to put it would be if the resulting code goes to stable or linux/master then it was a bug. But we can't expect from the user to know if the problem is stable material, or even whether their problem is a bug in the first place. Simple example - WiFi cards which don't support AP mode. User may try to run an AP, and report it doesn't work. They may not know whether it's HW limitation or a bug. The maintainer responding with "it's not supported, sorry" does not seem to me to be a high bar. Also, in my defense, I do give a rough ballpark of what we consider to be a problem we expect to be addressed: ... bug reports of reasonable quality. The bug reports range from users reporting real life crashes, thru errors discovered in fuzzing to reports of issues with the code found by static analysis tools and new compiler warnings. Just in case someone thought that maintainers are their tech support. Then again, I don't want to completely exclude technical questions which aren't straight up crashes because some of those are reasonable, should be answered or even result in improving docs or error reporting. It's a balancing act :(
