From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Joe Perches <joe@perches.com>,
Andrew Morton <akpm@linux-foundation.org>,
workflows@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
Thorsten Leemhuis <linux@leemhuis.info>,
Kees Cook <kees@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/2] get_maintainer: report subsystem status separately from maintainer role
Date: Tue, 4 Feb 2025 10:12:39 +0000 [thread overview]
Message-ID: <f7c4d355-3a3d-4757-8f76-94f4303925be@lucifer.local> (raw)
In-Reply-To: <20250203-b4-get_maintainer-v2-0-83ba008b491f@suse.cz>
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@suse.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@suse.cz>
>
prev parent reply other threads:[~2025-02-04 10:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-03 11:13 Vlastimil Babka
2025-02-03 11:13 ` [PATCH v2 1/2] get_maintainer: add --substatus for reporting subsystem status Vlastimil Babka
2025-02-04 10:19 ` Lorenzo Stoakes
2025-02-11 10:32 ` Uwe Kleine-König
2025-02-11 10:48 ` Geert Uytterhoeven
2025-02-11 10:59 ` Vlastimil Babka
2025-02-11 11:05 ` Vlastimil Babka
2025-02-11 15:19 ` Geert Uytterhoeven
2025-02-11 15:30 ` Vlastimil Babka
2025-02-11 16:28 ` Geert Uytterhoeven
2025-02-11 18:39 ` Vlastimil Babka
2025-02-11 15:09 ` Uwe Kleine-König
2025-02-11 15:22 ` Geert Uytterhoeven
2025-02-11 15:20 ` Vlastimil Babka
2025-02-12 12:42 ` Geert Uytterhoeven
2025-02-12 14:53 ` Uwe Kleine-König
2025-02-03 11:13 ` [PATCH v2 2/2] get_maintainer: stop reporting subsystem status as maintainer role Vlastimil Babka
2025-02-04 10:18 ` Lorenzo Stoakes
2025-02-04 10:12 ` Lorenzo Stoakes [this message]
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=f7c4d355-3a3d-4757-8f76-94f4303925be@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=bryan.odonoghue@linaro.org \
--cc=joe@perches.com \
--cc=kees@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox