Message-ID: <f7c4d355-3a3d-4757-8f76-94f4303925be@lucifer.local>
Date: Tue, 4 Feb 2025 10:12:39 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: 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
Subject: Re: [PATCH v2 0/2] get_maintainer: report subsystem status
 separately from maintainer role

On Mon, Feb 03, 2025 at 12:13:15PM +0100, Vlastimil Babka wrote:
> The subsystem status (S: field) can inform a patch submitter if the
> subsystem is well maintained or e.g. maintainers are missing. In
> get_maintainer, it is currently reported with --role(stats) by adjusting
> the maintainer role for any status different from Maintained.  This has
> two downsides:
>
> - if a subsystem has only reviewers or mailing lists and no maintainers,
>   the status is not reported. For example Orphan subsystems typically
>   have no maintainers so there's nobody to report as orphan minder.
>
> - the Supported status means that someone is paid for maintaining, but
>   it is reported as "supporter" for all the maintainers, which can be
>   incorrect (only some of them may be paid). People (including myself)
>   have been also confused about what "supporter" means.

Myself included! Thanks for this.

I don't think it's a distinction that is really meaningful from a practical
perspective, but even if one feels this is useful, as you say, it can't deal
with a mix of paid and non-paid maintainers.

>
> The second point has been brought up in 2022 and the discussion in the
> end resulted in adjusting documentation only [1]. I however agree with
> Ted's points that it's misleading to take the subsystem status and apply
> it to all maintainers [2].
>
> The attempt to modify get_maintainer output was retracted after Joe
> objected that the status becomes not reported at all [3]. This series
> addresses that concern by reporting the status (unless it's the most
> common Maintained one) on separate lines that follow the reported
> emails, using a new --substatus parameter. Care is taken to reduce the
> noise to minimum by not reporting the most common Maintained status, by
> detault require no opt-in that would need the users to discover the new
> parameter, and at the same time not to break existing git --cc-cmd
> usage.
>
> The advantage of these changes is that subsystem status is now reported
> also for subsystems with no maintainers, and maintainers are reported as
> maintainers.
>
> Changes since v1 [4]
> - Change the approach to report subsystem status on separate lines via
>   the new (effectively enabled by default) --substatus option. The
>   "SUBSYSTEM [status]" output felt more and more clumsy.
> - Drop R-b from Kees due to the major change of approach.
>
> [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/
> [4] https://lore.kernel.org/r/20250114-b4-get_maintainer-v1-0-ecf40f0d032d@suse.cz
>
> Signed-off-by: Vlastimil Babka <vbabka@...e.cz>
> ---
> Vlastimil Babka (2):
>       get_maintainer: add --substatus for reporting subsystem status
>       get_maintainer: stop reporting subsystem status as maintainer role
>
>  scripts/get_maintainer.pl | 49 ++++++++++++++++++++++++++++++-----------------
>  1 file changed, 31 insertions(+), 18 deletions(-)
> ---
> base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b
> change-id: 20250114-b4-get_maintainer-cc3358be81c0
>
> Best regards,
> --
> Vlastimil Babka <vbabka@...e.cz>
>

Powered by blists - more mailing lists