linux-kernel - Re: [PATCH v2 1/2] get_maintainer: add --substatus for reporting subsystem status

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: <68bb307a-26ad-46ac-a9de-bec9b808506a@suse.cz>
Date: Tue, 11 Feb 2025 16:30:48 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Uwe Kleine-König <u.kleine-koenig@...libre.com>,
 Joe Perches <joe@...ches.com>, Andrew Morton <akpm@...ux-foundation.org>,
 workflows@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
 Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
 Thorsten Leemhuis <linux@...mhuis.info>, Kees Cook <kees@...nel.org>,
 linux-kernel@...r.kernel.org, regressions@...ts.linux.dev
Subject: Re: [PATCH v2 1/2] get_maintainer: add --substatus for reporting
 subsystem status

On 2/11/25 16:19, Geert Uytterhoeven wrote:
> Hi Vlastimil,
> 
> On Tue, 11 Feb 2025 at 15:58, Vlastimil Babka <vbabka@...e.cz> wrote:
>> On 2/11/25 11:48, Geert Uytterhoeven wrote:
>> I've tried to do that in v1 in the form of reporting e.g. as
>> John Doe <jd@...mple.com> (maintainer:SUBSYSTEM [supported])
>>
>> But it seemed noisy to repeat that on every line involving the subsystem.
> 
> Yeah, it could be considered noisy... (more below)
> 
>> When you say comment, what kind of separation for the comment would work
>> regardless of what's used for postprocessing?
> 
> I don't mind much. Perhaps just a comma?

Hm comma where exactly? Sorry I might not get it, could you provide a full
example? Thanks.

>> > Now, as both Uwe and I edit our generated scripts before running them,
>> > we can delete the unwanted lines, but it's more work...
>> > Thanks!
>>
>> I guess technically your scripts could detect first if --no-substatus is
>> supported by grepping --help or testing if passing the option results in an
>> error? But yeah it's not ideal, looks like I've hit the limits of automagic
>> heuristics here.
>> Or we make it fully opt-in but then most non-scripting users will not learn
>> the status at all because it won't occur to them to enable it...
> 
> I still seem to miss the real story behind this patch (so perhaps
> that's why I would consider all of it noisy ;-). When I create a patch,

The cover letter tells the story. It comes back to the way the script
reports maintainers as "supporter"s (or other roles according to the status,
however some status means there is most likely no maintainer). Joe objected
to that status reporting would be simply removed in [1]. I also think it's
useful information for the submitters, so I try to provide it differently.

> what am I gonna do with this extra information?
> E.g. decide not to send the patch, because the driver is orphaned?

Well for example you can know that you might not get a timely reply, or
might need to step up as a maintainer. Or you're trying to add a feature and
the driver is "odd fixes". I think we do document the status in MAINTAINERS
for a reason, and one could expect the tool to provide it and not require
you to go look into MAINTAINERS yourself.

[1]
https://lore.kernel.org/all/30776fe75061951777da8fa6618ae89bea7a8ce4.camel@perches.com/

> Thanks!
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
>