On Fri, Jul 14, 2023 at 11:34:18AM -0700, Jakub Kicinski wrote: > 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. ... > 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. Sure, there's cases where it's really clear and people ought to reply but there's other things especially as you get into the automated reports - for things like the fuzzers with automated reports and sometimes janky bisection it's a lot more reasonable to just drop them on the floor. > 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 :( Honestly I think a lot of it is the "must" rather than "should", it comes over as being a bit inflexible.
Attachment:
signature.asc
Description: PGP signature
