linux-kernel - Re: [PATCH docs] docs: maintainer: document expectations of small time maintainers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 14 Jul 2023 21:02:12 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Thorsten Leemhuis <linux@...mhuis.info>, corbet@....net,
        workflows@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org
Subject: Re: [PATCH docs] docs: maintainer: document expectations of small
 time maintainers

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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)