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] [day] [month] [year] [list]

Message-ID: <7004ae2e-26f4-4c8c-b669-2bb983f9c653@suse.cz>
Date: Tue, 11 Feb 2025 19:39:44 +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 17:28, Geert Uytterhoeven wrote:
> Hi Vlastimil,
> 
> On Tue, 11 Feb 2025 at 17:09, Vlastimil Babka <vbabka@...e.cz> wrote:
>> On 2/11/25 16:19, Geert Uytterhoeven wrote:
>> > 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.
> 
> I was thinking something like:
> 
>     John Doe <jd@...mple.com> (maintainer:SUBSYSTEM, supported)
> 
> But I guess your example above
> 
>     John Doe <jd@...mple.com> (maintainer:SUBSYSTEM [supported])
> 
> would be fine, too.

OK, thanks. The fixup I posted to check for STDOUT being a tty does work for
your use case too? I hope if it does and there are no more surprises, we can
stick to the current approach.

>> >> > 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.
> 
> As the "S" field is separate from the (possibly multiple) "M" and "R"
> fields, it still doesn't tell you e.g. who of them "is actually paid
> to look after this" and who "actually looks after it"...

Sure, but that can only change if we decide to include that information per
person in MAINTAINERS. At least after my series it's not misleading by
labeling everyone as supporter.

> To me it looks overly complex. I send patches, and resend them, and
> invoke e.g. akpm if all else fails...

Right, but we should also think of newcomers who don't have all that
experience yet :)

>> [1]
>> https://lore.kernel.org/all/30776fe75061951777da8fa6618ae89bea7a8ce4.camel@perches.com/
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
>