linux-kernel - [PATCH v2 0/2] get_maintainer: report subsystem status separately from maintainer role

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250203-b4-get_maintainer-v2-0-83ba008b491f@suse.cz>
Date: Mon, 03 Feb 2025 12:13:15 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Joe Perches <joe@...ches.com>, 
 Andrew Morton <akpm@...ux-foundation.org>
Cc: 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, Vlastimil Babka <vbabka@...e.cz>
Subject: [PATCH v2 0/2] get_maintainer: report subsystem status separately
 from maintainer role

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.

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>