From: Kees Cook <kees@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Joe Perches <joe@perches.com>,
workflows@vger.kernel.org, linux-kernel@vger.kernel.org,
Theodore Ts'o <tytso@mit.edu>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
Thorsten Leemhuis <linux@leemhuis.info>
Subject: Re: [RFC PATCH] get_maintainer: decouple subsystem status from maintainer role
Date: Tue, 17 Dec 2024 21:48:51 -0800 [thread overview]
Message-ID: <202412172145.78ED0178@keescook> (raw)
In-Reply-To: <20241213112921.180978-2-vbabka@suse.cz>
On Fri, Dec 13, 2024 at 12:29:22PM +0100, Vlastimil Babka wrote:
> The script currently uses the subystem's status (S: field) to change how
> maintainers are reported. One prominent example is when the status is
> Supported, the maintainers are reported as "(supporter:SUBSYSTEM)".
>
> This is misleading, as the Supported status defined as "Someone is
> actually paid to look after this." may not in fact apply to everyone
> listed as a maintainer, but only to some of them.
>
> It has also been confusing people to what "supporter" means and has
> required updates to the documentation [1].
>
> Thus stop applying the subsystem status to change "maintainer:" to
> anything else, as maintainers are maintainers. Instead, if the subsystem
> status is not the most common one (Maintained), indicate it as part of
> the subsystem name. So for example, instead of "(supporter:SUBSYSTEM)"
> report "(maintainer:SUBSYSTEM [supported])".
>
> [1] https://lore.kernel.org/all/20221006162413.858527-1-bryan.odonoghue@linaro.org/
>
> Cc: "Theodore Ts'o" <tytso@mit.edu>
> Cc: "Bryan O'Donoghue" <bryan.odonoghue@linaro.org>
> Cc: Thorsten Leemhuis <linux@leemhuis.info>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Kees Cook <kees@kernel.org>
> ---
> I have been confused myself in the past seeing "supporter" and have seen
> somebody recently wondering what it means as well.
>
> I have read the threads from 2022 that in the end resulted in adjusting
> documentation only [1]. I very much agree with Ted's points about taking
> the subsystem status and applying it to all maintainers being wrong [2].
>
> The attempt to modify get_maintainer output was retracted after Joe
> objected that the status becomes not reported at all [3]. This RFC
> attempts to address that by reporting the status (unless it's the most
> common one) as part of the subsystem.
>
> The patch is not perfect, as with this approach, the logical thing would
> be to do the same also for reviewers and mailing lists. In fact,
> subsystems with a status of Orphan typically only have some catch-all
> mailing list and no maintainers, so the "(orphan minder:SUBSYSTEM)"
> would never be currently reported by checkpatch. It would be thus
> logical to report the status in the same way for lists (and reviewers).
>
> But I didn't attempt a full implementation as I'm not fluent in Perl and
> would like to see if we can get a consensus first. If we do, I don't
> insist in this particular "SUBSYSTEM [status]" syntax nor on
> implementing the full solution myself - I would be happy if somebody
> else did. My main point is that maintainer is a maintainer and the
> subsystem status should be indicated for the subsystem, not for the
> maintainer.
>
> [1] https://lore.kernel.org/all/20221006162413.858527-1-bryan.odonoghue@linaro.org/
> [2] https://lore.kernel.org/all/Yzen4X1Na0MKXHs9@mit.edu/
> [3] https://lore.kernel.org/all/30776fe75061951777da8fa6618ae89bea7a8ce4.camel@perches.com/
Do we want to change "Supported" to "Funded" to help clear up the
meaning? (But yes, I agree, that the subsystem status should be applied
to the subsystem, not the individual contacts.)
-Kees
--
Kees Cook
next prev parent reply other threads:[~2024-12-18 5:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-13 11:29 [RFC PATCH] get_maintainer: decouple subsystem status from maintainer role Vlastimil Babka
2024-12-18 5:48 ` Kees Cook [this message]
2025-01-06 18:21 ` Thorsten Leemhuis
2025-01-13 14:55 ` Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202412172145.78ED0178@keescook \
--to=kees@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=tytso@mit.edu \
--cc=vbabka@suse.cz \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.