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

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Vlastimil,

On Tue, 11 Feb 2025 at 17:09, Vlastimil Babka <vbabka@suse.cz> wrote:
> On 2/11/25 16:19, Geert Uytterhoeven wrote:
> > On Tue, 11 Feb 2025 at 15:58, Vlastimil Babka <vbabka@suse.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@example.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@example.com> (maintainer:SUBSYSTEM, supported)

But I guess your example above

    John Doe <jd@example.com> (maintainer:SUBSYSTEM [supported])

would be fine, too.

> >> > 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"...

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

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

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds