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]

Message-ID: <20230714113418.49dfac7e@kernel.org>
Date:   Fri, 14 Jul 2023 11:34:18 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Mark Brown <broonie@...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, 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 :(