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

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

[Vlastimil Babka]

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@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>

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

[Vlastimil Babka]

The subsystem status 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 (i.e. typically, Orphan subsystems have no
  maintainers)

- the Supported status means that someone is paid for maintaining, but
  it is reported as "supporter" for all the maintainers, which can be
  incorrect. People have been also confused about what "supporter"
  means.

This patch introduces a new --substatus option and functionality aimed
to report the subsystem status separately, without adjusting the
reported maintainer role. After the e-mails are output, the status of
subsystems will follow, for example:

...
linux-kernel@vger.kernel.org (open list:LIBRARY CODE)
LIBRARY CODE status: Supported

In order to allow replacing the role rewriting seamlessly, the new
option works as follows:

- it is automatically enabled when --email and --role are enabled
  (the defaults include --email and --rolestats which implies --role)

- usages with --norolestats e.g. for git's --cc-cmd will thus need no
  adjustments

- the most common Maintained status is not reported at all, to reduce
  unnecessary noise

- THE REST catch-all section (contains lkml) status is not reported

- the existing --subsystem and --status options are unaffected so their
  users will need no adjustments

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
 scripts/get_maintainer.pl | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 5ac02e19873722d0f5bf3ac8de8374338c7bddc3..da7fc70f17cd8d46b45da8db0b2029bb11b25af1 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -50,6 +50,7 @@ my $output_multiline = 1;
 my $output_separator = ", ";
 my $output_roles = 0;
 my $output_rolestats = 1;
+my $output_substatus = undef;
 my $output_section_maxlen = 50;
 my $scm = 0;
 my $tree = 1;
@@ -269,6 +270,7 @@ if (!GetOptions(
 		'separator=s' => \$output_separator,
 		'subsystem!' => \$subsystem,
 		'status!' => \$status,
+		'substatus!' => \$output_substatus,
 		'scm!' => \$scm,
 		'tree!' => \$tree,
 		'web!' => \$web,
@@ -314,6 +316,10 @@ $output_multiline = 0 if ($output_separator ne ", ");
 $output_rolestats = 1 if ($interactive);
 $output_roles = 1 if ($output_rolestats);
 
+if (!defined $output_substatus) {
+    $output_substatus = $email && $output_roles;
+}
+
 if ($sections || $letters ne "") {
     $sections = 1;
     $email = 0;
@@ -637,6 +643,7 @@ my @web = ();
 my @bug = ();
 my @subsystem = ();
 my @status = ();
+my @substatus = ();
 my %deduplicate_name_hash = ();
 my %deduplicate_address_hash = ();
 
@@ -651,6 +658,11 @@ if ($scm) {
     output(@scm);
 }
 
+if ($output_substatus) {
+    @substatus = uniq(@substatus);
+    output(@substatus);
+}
+
 if ($status) {
     @status = uniq(@status);
     output(@status);
@@ -859,6 +871,7 @@ sub get_maintainers {
     @bug = ();
     @subsystem = ();
     @status = ();
+    @substatus = ();
     %deduplicate_name_hash = ();
     %deduplicate_address_hash = ();
     if ($email_git_all_signature_types) {
@@ -1073,6 +1086,7 @@ version: $V
     --remove-duplicates => minimize duplicate email names/addresses
     --roles => show roles (status:subsystem, git-signer, list, etc...)
     --rolestats => show roles and statistics (commits/total_commits, %)
+    --substatus => show subsystem status if not Maintained (default: match --roles)"
     --file-emails => add email addresses found in -f file (default: 0 (off))
     --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on))
   --scm => print SCM tree(s) if any
@@ -1335,7 +1349,9 @@ sub add_categories {
     my $start = find_starting_index($index);
     my $end = find_ending_index($index);
 
-    push(@subsystem, $typevalue[$start]);
+    my $subsystem = $typevalue[$start];
+    push(@subsystem, $subsystem);
+    my $status = "Unknown";
 
     for ($i = $start + 1; $i < $end; $i++) {
 	my $tv = $typevalue[$i];
@@ -1386,8 +1402,8 @@ sub add_categories {
 		}
 	    } elsif ($ptype eq "R") {
 		if ($email_reviewer) {
-		    my $subsystem = get_subsystem_name($i);
-		    push_email_addresses($pvalue, "reviewer:$subsystem" . $suffix);
+		    my $subs = get_subsystem_name($i);
+		    push_email_addresses($pvalue, "reviewer:$subs" . $suffix);
 		}
 	    } elsif ($ptype eq "T") {
 		push(@scm, $pvalue . $suffix);
@@ -1397,9 +1413,14 @@ sub add_categories {
 		push(@bug, $pvalue . $suffix);
 	    } elsif ($ptype eq "S") {
 		push(@status, $pvalue . $suffix);
+		$status = $pvalue;
 	    }
 	}
     }
+
+    if ($subsystem ne "THE REST" and $status ne "Maintained") {
+	push(@substatus, $subsystem . " status: " . $status . $suffix)
+    }
 }
 
 sub email_inuse {
@@ -1903,6 +1924,7 @@ EOT
 		$done = 1;
 		$output_rolestats = 0;
 		$output_roles = 0;
+		$output_substatus = 0;
 		last;
 	    } elsif ($nr =~ /^\d+$/ && $nr > 0 && $nr <= $count) {
 		$selected{$nr - 1} = !$selected{$nr - 1};

-- 
2.48.1

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

[Lorenzo Stoakes]

On Mon, Feb 03, 2025 at 12:13:16PM +0100, Vlastimil Babka wrote:
> The subsystem status 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 (i.e. typically, Orphan subsystems have no
>   maintainers)
>
> - the Supported status means that someone is paid for maintaining, but
>   it is reported as "supporter" for all the maintainers, which can be
>   incorrect. People have been also confused about what "supporter"
>   means.
>
> This patch introduces a new --substatus option and functionality aimed
> to report the subsystem status separately, without adjusting the
> reported maintainer role. After the e-mails are output, the status of
> subsystems will follow, for example:
>
> ...
> linux-kernel@vger.kernel.org (open list:LIBRARY CODE)
> LIBRARY CODE status: Supported
>
> In order to allow replacing the role rewriting seamlessly, the new
> option works as follows:
>
> - it is automatically enabled when --email and --role are enabled
>   (the defaults include --email and --rolestats which implies --role)
>
> - usages with --norolestats e.g. for git's --cc-cmd will thus need no
>   adjustments
>
> - the most common Maintained status is not reported at all, to reduce
>   unnecessary noise
>
> - THE REST catch-all section (contains lkml) status is not reported
>
> - the existing --subsystem and --status options are unaffected so their
>   users will need no adjustments
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>

This LGTM afaict, and makes sense, so:

Acked-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

> ---
>  scripts/get_maintainer.pl | 28 +++++++++++++++++++++++++---
>  1 file changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index 5ac02e19873722d0f5bf3ac8de8374338c7bddc3..da7fc70f17cd8d46b45da8db0b2029bb11b25af1 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -50,6 +50,7 @@ my $output_multiline = 1;
>  my $output_separator = ", ";
>  my $output_roles = 0;
>  my $output_rolestats = 1;
> +my $output_substatus = undef;
>  my $output_section_maxlen = 50;
>  my $scm = 0;
>  my $tree = 1;
> @@ -269,6 +270,7 @@ if (!GetOptions(
>  		'separator=s' => \$output_separator,
>  		'subsystem!' => \$subsystem,
>  		'status!' => \$status,
> +		'substatus!' => \$output_substatus,
>  		'scm!' => \$scm,
>  		'tree!' => \$tree,
>  		'web!' => \$web,
> @@ -314,6 +316,10 @@ $output_multiline = 0 if ($output_separator ne ", ");
>  $output_rolestats = 1 if ($interactive);
>  $output_roles = 1 if ($output_rolestats);
>
> +if (!defined $output_substatus) {
> +    $output_substatus = $email && $output_roles;
> +}
> +
>  if ($sections || $letters ne "") {
>      $sections = 1;
>      $email = 0;
> @@ -637,6 +643,7 @@ my @web = ();
>  my @bug = ();
>  my @subsystem = ();
>  my @status = ();
> +my @substatus = ();
>  my %deduplicate_name_hash = ();
>  my %deduplicate_address_hash = ();
>
> @@ -651,6 +658,11 @@ if ($scm) {
>      output(@scm);
>  }
>
> +if ($output_substatus) {
> +    @substatus = uniq(@substatus);
> +    output(@substatus);
> +}
> +
>  if ($status) {
>      @status = uniq(@status);
>      output(@status);
> @@ -859,6 +871,7 @@ sub get_maintainers {
>      @bug = ();
>      @subsystem = ();
>      @status = ();
> +    @substatus = ();
>      %deduplicate_name_hash = ();
>      %deduplicate_address_hash = ();
>      if ($email_git_all_signature_types) {
> @@ -1073,6 +1086,7 @@ version: $V
>      --remove-duplicates => minimize duplicate email names/addresses
>      --roles => show roles (status:subsystem, git-signer, list, etc...)
>      --rolestats => show roles and statistics (commits/total_commits, %)
> +    --substatus => show subsystem status if not Maintained (default: match --roles)"
>      --file-emails => add email addresses found in -f file (default: 0 (off))
>      --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on))
>    --scm => print SCM tree(s) if any
> @@ -1335,7 +1349,9 @@ sub add_categories {
>      my $start = find_starting_index($index);
>      my $end = find_ending_index($index);
>
> -    push(@subsystem, $typevalue[$start]);
> +    my $subsystem = $typevalue[$start];
> +    push(@subsystem, $subsystem);
> +    my $status = "Unknown";
>
>      for ($i = $start + 1; $i < $end; $i++) {
>  	my $tv = $typevalue[$i];
> @@ -1386,8 +1402,8 @@ sub add_categories {
>  		}
>  	    } elsif ($ptype eq "R") {
>  		if ($email_reviewer) {
> -		    my $subsystem = get_subsystem_name($i);
> -		    push_email_addresses($pvalue, "reviewer:$subsystem" . $suffix);
> +		    my $subs = get_subsystem_name($i);
> +		    push_email_addresses($pvalue, "reviewer:$subs" . $suffix);
>  		}
>  	    } elsif ($ptype eq "T") {
>  		push(@scm, $pvalue . $suffix);
> @@ -1397,9 +1413,14 @@ sub add_categories {
>  		push(@bug, $pvalue . $suffix);
>  	    } elsif ($ptype eq "S") {
>  		push(@status, $pvalue . $suffix);
> +		$status = $pvalue;
>  	    }
>  	}
>      }
> +
> +    if ($subsystem ne "THE REST" and $status ne "Maintained") {
> +	push(@substatus, $subsystem . " status: " . $status . $suffix)
> +    }
>  }
>
>  sub email_inuse {
> @@ -1903,6 +1924,7 @@ EOT
>  		$done = 1;
>  		$output_rolestats = 0;
>  		$output_roles = 0;
> +		$output_substatus = 0;
>  		last;
>  	    } elsif ($nr =~ /^\d+$/ && $nr > 0 && $nr <= $count) {
>  		$selected{$nr - 1} = !$selected{$nr - 1};
>
> --
> 2.48.1
>

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

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 4817 bytes --]

Hello,

On Mon, Feb 03, 2025 at 12:13:16PM +0100, Vlastimil Babka wrote:
> The subsystem status 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 (i.e. typically, Orphan subsystems have no
>   maintainers)
> 
> - the Supported status means that someone is paid for maintaining, but
>   it is reported as "supporter" for all the maintainers, which can be
>   incorrect. People have been also confused about what "supporter"
>   means.
> 
> This patch introduces a new --substatus option and functionality aimed
> to report the subsystem status separately, without adjusting the
> reported maintainer role. After the e-mails are output, the status of
> subsystems will follow, for example:
> 
> ...
> linux-kernel@vger.kernel.org (open list:LIBRARY CODE)
> LIBRARY CODE status: Supported
> 
> In order to allow replacing the role rewriting seamlessly, the new
> option works as follows:
> 
> - it is automatically enabled when --email and --role are enabled
>   (the defaults include --email and --rolestats which implies --role)
> 
> - usages with --norolestats e.g. for git's --cc-cmd will thus need no
>   adjustments
> 
> - the most common Maintained status is not reported at all, to reduce
>   unnecessary noise
> 
> - THE REST catch-all section (contains lkml) status is not reported
> 
> - the existing --subsystem and --status options are unaffected so their
>   users will need no adjustments
> 
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>

This patch is in next as c1565b6f7b53ea1ea3e757538832e12d7d13d949. It
breaks one of my scripts that I use to semi-automatically determine
recipents for patch series.

It works as follows:

	$ batch-add-recipents audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
	#!/bin/sh

	addrecipent \
	-t "Rob Herring <robh@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
	-t "Krzysztof Kozlowski <krzk+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
	-t "Conor Dooley <conor+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
	-t "Neil Armstrong <neil.armstrong@linaro.org>" $(: maintainer:ARM/Amlogic Meson SoC support) \
	-t "Kevin Hilman <khilman@baylibre.com>" $(: maintainer:ARM/Amlogic Meson SoC support) \
	-c "Jerome Brunet <jbrunet@baylibre.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
	-c "Martin Blumenstingl <martin.blumenstingl@googlemail.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
	-t "Liam Girdwood <lgirdwood@gmail.com>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
	-t "Mark Brown <broonie@kernel.org>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
	-t "Jaroslav Kysela <perex@perex.cz>" $(: maintainer:SOUND) \
	-t "Takashi Iwai <tiwai@suse.com>" $(: maintainer:SOUND) \
	-c "devicetree@vger.kernel.org" $(: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
	-c "linux-arm-kernel@lists.infradead.org" $(: moderated list:ARM/Amlogic Meson SoC support) \
	-c "linux-amlogic@lists.infradead.org" $(: open list:ARM/Amlogic Meson SoC support) \
	-c "linux-kernel@vger.kernel.org" $(: open list) \
	-c "linux-sound@vger.kernel.org" $(: open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
	audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch

the output is usually redirected to a file that I edit before running
it. The additional line in the output of

	scripts/get_maintainer.pl audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch

with your change breaks that script.

#regzbot introduced: c1565b6f7b53ea1ea3e757538832e12d7d13d949
#regzbot title: get_maintainer's subsystem status output breaks custom script

I can cope with it, but still wanted to let you know that people use
get_maintainers for `git --cc-cmd`-like usages without --norolestats.

Given that I use scripts/get_maintainer.pl from the tree I currently
work at and sometimes that is based on next, sometimes on linus/master
or -rc1 and sometimes even older trees (e.g. stable), the introduced
`--no-substatus` option doesn't help me because when run from a tree
without your change I get:

	$ scripts/get_maintainer.pl --no-substatus audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
	Unknown option: no-substatus
	scripts/get_maintainer.pl: invalid argument - use --help if necessary

so I cannot use that option easily until all the trees I care about get
your change. :-\

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Geert Uytterhoeven]

Hi Uwe,

On Tue, 11 Feb 2025 at 11:32, Uwe Kleine-König
<u.kleine-koenig@baylibre.com> wrote:
> On Mon, Feb 03, 2025 at 12:13:16PM +0100, Vlastimil Babka wrote:
> > The subsystem status 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 (i.e. typically, Orphan subsystems have no
> >   maintainers)
> >
> > - the Supported status means that someone is paid for maintaining, but
> >   it is reported as "supporter" for all the maintainers, which can be
> >   incorrect. People have been also confused about what "supporter"
> >   means.
> >
> > This patch introduces a new --substatus option and functionality aimed
> > to report the subsystem status separately, without adjusting the
> > reported maintainer role. After the e-mails are output, the status of
> > subsystems will follow, for example:
> >
> > ...
> > linux-kernel@vger.kernel.org (open list:LIBRARY CODE)
> > LIBRARY CODE status: Supported
> >
> > In order to allow replacing the role rewriting seamlessly, the new
> > option works as follows:
> >
> > - it is automatically enabled when --email and --role are enabled
> >   (the defaults include --email and --rolestats which implies --role)
> >
> > - usages with --norolestats e.g. for git's --cc-cmd will thus need no
> >   adjustments
> >
> > - the most common Maintained status is not reported at all, to reduce
> >   unnecessary noise
> >
> > - THE REST catch-all section (contains lkml) status is not reported
> >
> > - the existing --subsystem and --status options are unaffected so their
> >   users will need no adjustments
> >
> > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>
> This patch is in next as c1565b6f7b53ea1ea3e757538832e12d7d13d949. It
> breaks one of my scripts that I use to semi-automatically determine
> recipents for patch series.
>
> It works as follows:
>
>         $ batch-add-recipents audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
>         #!/bin/sh
>
>         addrecipent \
>         -t "Rob Herring <robh@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>         -t "Krzysztof Kozlowski <krzk+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>         -t "Conor Dooley <conor+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>         -t "Neil Armstrong <neil.armstrong@linaro.org>" $(: maintainer:ARM/Amlogic Meson SoC support) \
>         -t "Kevin Hilman <khilman@baylibre.com>" $(: maintainer:ARM/Amlogic Meson SoC support) \
>         -c "Jerome Brunet <jbrunet@baylibre.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
>         -c "Martin Blumenstingl <martin.blumenstingl@googlemail.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
>         -t "Liam Girdwood <lgirdwood@gmail.com>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
>         -t "Mark Brown <broonie@kernel.org>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
>         -t "Jaroslav Kysela <perex@perex.cz>" $(: maintainer:SOUND) \
>         -t "Takashi Iwai <tiwai@suse.com>" $(: maintainer:SOUND) \
>         -c "devicetree@vger.kernel.org" $(: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>         -c "linux-arm-kernel@lists.infradead.org" $(: moderated list:ARM/Amlogic Meson SoC support) \
>         -c "linux-amlogic@lists.infradead.org" $(: open list:ARM/Amlogic Meson SoC support) \
>         -c "linux-kernel@vger.kernel.org" $(: open list) \
>         -c "linux-sound@vger.kernel.org" $(: open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
>         audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch

Hey, that looks familiar ;-)

> the output is usually redirected to a file that I edit before running
> it. The additional line in the output of
>
>         scripts/get_maintainer.pl audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
>
> with your change breaks that script.

You forgot to list the additional output?

I gave it a try with my script, and with one of my own patches.
Example additional output is:

     --cc "ARM/Microchip" $(: AT91] SoC support status: Supported \
    --cc "QAT DRIVER status: Supported \
    --cc "ARM/ASPEED MACHINE SUPPORT status: Supported \
    --cc "MELEXIS MLX90614 DRIVER status: Supported \
    --cc "ARM/NUVOTON MA35 ARCHITECTURE status: Supported \
    --cc "ARM/RISC-V/RENESAS ARCHITECTURE status: Supported \

Iff this extra output is good to have, why not include it in the comment
next to the existing entries with the email addresses, so it will be
handled automatically by all scripting on top?

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!

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

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

[Vlastimil Babka]

On 2/11/25 11:48, Geert Uytterhoeven wrote:
> Hi Uwe,
> 
> On Tue, 11 Feb 2025 at 11:32, Uwe Kleine-König
> <u.kleine-koenig@baylibre.com> wrote:
>> On Mon, Feb 03, 2025 at 12:13:16PM +0100, Vlastimil Babka wrote:
>> > The subsystem status 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 (i.e. typically, Orphan subsystems have no
>> >   maintainers)
>> >
>> > - the Supported status means that someone is paid for maintaining, but
>> >   it is reported as "supporter" for all the maintainers, which can be
>> >   incorrect. People have been also confused about what "supporter"
>> >   means.
>> >
>> > This patch introduces a new --substatus option and functionality aimed
>> > to report the subsystem status separately, without adjusting the
>> > reported maintainer role. After the e-mails are output, the status of
>> > subsystems will follow, for example:
>> >
>> > ...
>> > linux-kernel@vger.kernel.org (open list:LIBRARY CODE)
>> > LIBRARY CODE status: Supported
>> >
>> > In order to allow replacing the role rewriting seamlessly, the new
>> > option works as follows:
>> >
>> > - it is automatically enabled when --email and --role are enabled
>> >   (the defaults include --email and --rolestats which implies --role)
>> >
>> > - usages with --norolestats e.g. for git's --cc-cmd will thus need no
>> >   adjustments
>> >
>> > - the most common Maintained status is not reported at all, to reduce
>> >   unnecessary noise
>> >
>> > - THE REST catch-all section (contains lkml) status is not reported
>> >
>> > - the existing --subsystem and --status options are unaffected so their
>> >   users will need no adjustments
>> >
>> > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>>
>> This patch is in next as c1565b6f7b53ea1ea3e757538832e12d7d13d949. It
>> breaks one of my scripts that I use to semi-automatically determine
>> recipents for patch series.
>>
>> It works as follows:
>>
>>         $ batch-add-recipents audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
>>         #!/bin/sh
>>
>>         addrecipent \
>>         -t "Rob Herring <robh@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>>         -t "Krzysztof Kozlowski <krzk+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>>         -t "Conor Dooley <conor+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>>         -t "Neil Armstrong <neil.armstrong@linaro.org>" $(: maintainer:ARM/Amlogic Meson SoC support) \
>>         -t "Kevin Hilman <khilman@baylibre.com>" $(: maintainer:ARM/Amlogic Meson SoC support) \
>>         -c "Jerome Brunet <jbrunet@baylibre.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
>>         -c "Martin Blumenstingl <martin.blumenstingl@googlemail.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
>>         -t "Liam Girdwood <lgirdwood@gmail.com>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
>>         -t "Mark Brown <broonie@kernel.org>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
>>         -t "Jaroslav Kysela <perex@perex.cz>" $(: maintainer:SOUND) \
>>         -t "Takashi Iwai <tiwai@suse.com>" $(: maintainer:SOUND) \
>>         -c "devicetree@vger.kernel.org" $(: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>>         -c "linux-arm-kernel@lists.infradead.org" $(: moderated list:ARM/Amlogic Meson SoC support) \
>>         -c "linux-amlogic@lists.infradead.org" $(: open list:ARM/Amlogic Meson SoC support) \
>>         -c "linux-kernel@vger.kernel.org" $(: open list) \
>>         -c "linux-sound@vger.kernel.org" $(: open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
>>         audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
> 
> Hey, that looks familiar ;-)
> 
>> the output is usually redirected to a file that I edit before running
>> it. The additional line in the output of
>>
>>         scripts/get_maintainer.pl audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
>>
>> with your change breaks that script.
> 
> You forgot to list the additional output?
> 
> I gave it a try with my script, and with one of my own patches.
> Example additional output is:
> 
>      --cc "ARM/Microchip" $(: AT91] SoC support status: Supported \
>     --cc "QAT DRIVER status: Supported \
>     --cc "ARM/ASPEED MACHINE SUPPORT status: Supported \
>     --cc "MELEXIS MLX90614 DRIVER status: Supported \
>     --cc "ARM/NUVOTON MA35 ARCHITECTURE status: Supported \
>     --cc "ARM/RISC-V/RENESAS ARCHITECTURE status: Supported \
> 
> Iff this extra output is good to have, why not include it in the comment
> next to the existing entries with the email addresses, so it will be
> handled automatically by all scripting on top?

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.

When you say comment, what kind of separation for the comment would work
regardless of what's used for postprocessing?

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

> Gr{oetje,eeting}s,
> 
>                         Geert
> 

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

[Vlastimil Babka]

On 2/11/25 11:59, Vlastimil Babka wrote:
> On 2/11/25 11:48, Geert Uytterhoeven wrote:
>> Hi Uwe,
>> 
>> On Tue, 11 Feb 2025 at 11:32, Uwe Kleine-König
>> <u.kleine-koenig@baylibre.com> wrote:
>>> On Mon, Feb 03, 2025 at 12:13:16PM +0100, Vlastimil Babka wrote:
>>> > The subsystem status 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 (i.e. typically, Orphan subsystems have no
>>> >   maintainers)
>>> >
>>> > - the Supported status means that someone is paid for maintaining, but
>>> >   it is reported as "supporter" for all the maintainers, which can be
>>> >   incorrect. People have been also confused about what "supporter"
>>> >   means.
>>> >
>>> > This patch introduces a new --substatus option and functionality aimed
>>> > to report the subsystem status separately, without adjusting the
>>> > reported maintainer role. After the e-mails are output, the status of
>>> > subsystems will follow, for example:
>>> >
>>> > ...
>>> > linux-kernel@vger.kernel.org (open list:LIBRARY CODE)
>>> > LIBRARY CODE status: Supported
>>> >
>>> > In order to allow replacing the role rewriting seamlessly, the new
>>> > option works as follows:
>>> >
>>> > - it is automatically enabled when --email and --role are enabled
>>> >   (the defaults include --email and --rolestats which implies --role)
>>> >
>>> > - usages with --norolestats e.g. for git's --cc-cmd will thus need no
>>> >   adjustments
>>> >
>>> > - the most common Maintained status is not reported at all, to reduce
>>> >   unnecessary noise
>>> >
>>> > - THE REST catch-all section (contains lkml) status is not reported
>>> >
>>> > - the existing --subsystem and --status options are unaffected so their
>>> >   users will need no adjustments
>>> >
>>> > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>>>
>>> This patch is in next as c1565b6f7b53ea1ea3e757538832e12d7d13d949. It
>>> breaks one of my scripts that I use to semi-automatically determine
>>> recipents for patch series.
>>>
>>> It works as follows:
>>>
>>>         $ batch-add-recipents audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
>>>         #!/bin/sh
>>>
>>>         addrecipent \
>>>         -t "Rob Herring <robh@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>>>         -t "Krzysztof Kozlowski <krzk+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>>>         -t "Conor Dooley <conor+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>>>         -t "Neil Armstrong <neil.armstrong@linaro.org>" $(: maintainer:ARM/Amlogic Meson SoC support) \
>>>         -t "Kevin Hilman <khilman@baylibre.com>" $(: maintainer:ARM/Amlogic Meson SoC support) \
>>>         -c "Jerome Brunet <jbrunet@baylibre.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
>>>         -c "Martin Blumenstingl <martin.blumenstingl@googlemail.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
>>>         -t "Liam Girdwood <lgirdwood@gmail.com>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
>>>         -t "Mark Brown <broonie@kernel.org>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
>>>         -t "Jaroslav Kysela <perex@perex.cz>" $(: maintainer:SOUND) \
>>>         -t "Takashi Iwai <tiwai@suse.com>" $(: maintainer:SOUND) \
>>>         -c "devicetree@vger.kernel.org" $(: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>>>         -c "linux-arm-kernel@lists.infradead.org" $(: moderated list:ARM/Amlogic Meson SoC support) \
>>>         -c "linux-amlogic@lists.infradead.org" $(: open list:ARM/Amlogic Meson SoC support) \
>>>         -c "linux-kernel@vger.kernel.org" $(: open list) \
>>>         -c "linux-sound@vger.kernel.org" $(: open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
>>>         audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
>> 
>> Hey, that looks familiar ;-)
>> 
>>> the output is usually redirected to a file that I edit before running
>>> it. The additional line in the output of
>>>
>>>         scripts/get_maintainer.pl audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
>>>
>>> with your change breaks that script.
>> 
>> You forgot to list the additional output?
>> 
>> I gave it a try with my script, and with one of my own patches.
>> Example additional output is:
>> 
>>      --cc "ARM/Microchip" $(: AT91] SoC support status: Supported \
>>     --cc "QAT DRIVER status: Supported \
>>     --cc "ARM/ASPEED MACHINE SUPPORT status: Supported \
>>     --cc "MELEXIS MLX90614 DRIVER status: Supported \
>>     --cc "ARM/NUVOTON MA35 ARCHITECTURE status: Supported \
>>     --cc "ARM/RISC-V/RENESAS ARCHITECTURE status: Supported \
>> 
>> Iff this extra output is good to have, why not include it in the comment
>> next to the existing entries with the email addresses, so it will be
>> handled automatically by all scripting on top?
> 
> 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.
> 
> When you say comment, what kind of separation for the comment would work
> regardless of what's used for postprocessing?
> 
>> 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.

Hm maybe I could add "-t STDOUT" to the heuristics?

> 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...
> 
>> Gr{oetje,eeting}s,
>> 
>>                         Geert
>> 
> 

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

[Geert Uytterhoeven]

Hi Vlastimil,

On Tue, 11 Feb 2025 at 15:58, Vlastimil Babka <vbabka@suse.cz> wrote:
> On 2/11/25 11:48, Geert Uytterhoeven wrote:
> > On Tue, 11 Feb 2025 at 11:32, Uwe Kleine-König
> > <u.kleine-koenig@baylibre.com> wrote:
> >> On Mon, Feb 03, 2025 at 12:13:16PM +0100, Vlastimil Babka wrote:
> >> > The subsystem status 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 (i.e. typically, Orphan subsystems have no
> >> >   maintainers)
> >> >
> >> > - the Supported status means that someone is paid for maintaining, but
> >> >   it is reported as "supporter" for all the maintainers, which can be
> >> >   incorrect. People have been also confused about what "supporter"
> >> >   means.
> >> >
> >> > This patch introduces a new --substatus option and functionality aimed
> >> > to report the subsystem status separately, without adjusting the
> >> > reported maintainer role. After the e-mails are output, the status of
> >> > subsystems will follow, for example:
> >> >
> >> > ...
> >> > linux-kernel@vger.kernel.org (open list:LIBRARY CODE)
> >> > LIBRARY CODE status: Supported
> >> >
> >> > In order to allow replacing the role rewriting seamlessly, the new
> >> > option works as follows:
> >> >
> >> > - it is automatically enabled when --email and --role are enabled
> >> >   (the defaults include --email and --rolestats which implies --role)
> >> >
> >> > - usages with --norolestats e.g. for git's --cc-cmd will thus need no
> >> >   adjustments
> >> >
> >> > - the most common Maintained status is not reported at all, to reduce
> >> >   unnecessary noise
> >> >
> >> > - THE REST catch-all section (contains lkml) status is not reported
> >> >
> >> > - the existing --subsystem and --status options are unaffected so their
> >> >   users will need no adjustments
> >> >
> >> > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> >>
> >> This patch is in next as c1565b6f7b53ea1ea3e757538832e12d7d13d949. It
> >> breaks one of my scripts that I use to semi-automatically determine
> >> recipents for patch series.
> >>
> >> It works as follows:
> >>
> >>         $ batch-add-recipents audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
> >>         #!/bin/sh
> >>
> >>         addrecipent \
> >>         -t "Rob Herring <robh@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
> >>         -t "Krzysztof Kozlowski <krzk+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
> >>         -t "Conor Dooley <conor+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
> >>         -t "Neil Armstrong <neil.armstrong@linaro.org>" $(: maintainer:ARM/Amlogic Meson SoC support) \
> >>         -t "Kevin Hilman <khilman@baylibre.com>" $(: maintainer:ARM/Amlogic Meson SoC support) \
> >>         -c "Jerome Brunet <jbrunet@baylibre.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
> >>         -c "Martin Blumenstingl <martin.blumenstingl@googlemail.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
> >>         -t "Liam Girdwood <lgirdwood@gmail.com>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
> >>         -t "Mark Brown <broonie@kernel.org>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
> >>         -t "Jaroslav Kysela <perex@perex.cz>" $(: maintainer:SOUND) \
> >>         -t "Takashi Iwai <tiwai@suse.com>" $(: maintainer:SOUND) \
> >>         -c "devicetree@vger.kernel.org" $(: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
> >>         -c "linux-arm-kernel@lists.infradead.org" $(: moderated list:ARM/Amlogic Meson SoC support) \
> >>         -c "linux-amlogic@lists.infradead.org" $(: open list:ARM/Amlogic Meson SoC support) \
> >>         -c "linux-kernel@vger.kernel.org" $(: open list) \
> >>         -c "linux-sound@vger.kernel.org" $(: open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
> >>         audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
> >
> > Hey, that looks familiar ;-)
> >
> >> the output is usually redirected to a file that I edit before running
> >> it. The additional line in the output of
> >>
> >>         scripts/get_maintainer.pl audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
> >>
> >> with your change breaks that script.
> >
> > You forgot to list the additional output?
> >
> > I gave it a try with my script, and with one of my own patches.
> > Example additional output is:
> >
> >      --cc "ARM/Microchip" $(: AT91] SoC support status: Supported \
> >     --cc "QAT DRIVER status: Supported \
> >     --cc "ARM/ASPEED MACHINE SUPPORT status: Supported \
> >     --cc "MELEXIS MLX90614 DRIVER status: Supported \
> >     --cc "ARM/NUVOTON MA35 ARCHITECTURE status: Supported \
> >     --cc "ARM/RISC-V/RENESAS ARCHITECTURE status: Supported \
> >
> > Iff this extra output is good to have, why not include it in the comment
> > next to the existing entries with the email addresses, so it will be
> > handled automatically by all scripting on top?
>
> 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?

> > 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,
what am I gonna do with this extra information?
E.g. decide not to send the patch, because the driver is orphaned?

Thanks!

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

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

[Vlastimil Babka]

On 2/11/25 16:19, Geert Uytterhoeven wrote:
> Hi Vlastimil,
> 
> 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.

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

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

> Thanks!
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

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

[Geert Uytterhoeven]

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

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

[Vlastimil Babka]

On 2/11/25 17:28, Geert Uytterhoeven wrote:
> 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.

OK, thanks. The fixup I posted to check for STDOUT being a tty does work for
your use case too? I hope if it does and there are no more surprises, we can
stick to the current approach.

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

Sure, but that can only change if we decide to include that information per
person in MAINTAINERS. At least after my series it's not misleading by
labeling everyone as supporter.

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

Right, but we should also think of newcomers who don't have all that
experience yet :)

>> [1]
>> https://lore.kernel.org/all/30776fe75061951777da8fa6618ae89bea7a8ce4.camel@perches.com/
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

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

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 7275 bytes --]

Hello Geert,

On Tue, Feb 11, 2025 at 11:48:13AM +0100, Geert Uytterhoeven wrote:
> On Tue, 11 Feb 2025 at 11:32, Uwe Kleine-König
> <u.kleine-koenig@baylibre.com> wrote:
> > On Mon, Feb 03, 2025 at 12:13:16PM +0100, Vlastimil Babka wrote:
> > > The subsystem status 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 (i.e. typically, Orphan subsystems have no
> > >   maintainers)
> > >
> > > - the Supported status means that someone is paid for maintaining, but
> > >   it is reported as "supporter" for all the maintainers, which can be
> > >   incorrect. People have been also confused about what "supporter"
> > >   means.
> > >
> > > This patch introduces a new --substatus option and functionality aimed
> > > to report the subsystem status separately, without adjusting the
> > > reported maintainer role. After the e-mails are output, the status of
> > > subsystems will follow, for example:
> > >
> > > ...
> > > linux-kernel@vger.kernel.org (open list:LIBRARY CODE)
> > > LIBRARY CODE status: Supported
> > >
> > > In order to allow replacing the role rewriting seamlessly, the new
> > > option works as follows:
> > >
> > > - it is automatically enabled when --email and --role are enabled
> > >   (the defaults include --email and --rolestats which implies --role)
> > >
> > > - usages with --norolestats e.g. for git's --cc-cmd will thus need no
> > >   adjustments
> > >
> > > - the most common Maintained status is not reported at all, to reduce
> > >   unnecessary noise
> > >
> > > - THE REST catch-all section (contains lkml) status is not reported
> > >
> > > - the existing --subsystem and --status options are unaffected so their
> > >   users will need no adjustments
> > >
> > > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> >
> > This patch is in next as c1565b6f7b53ea1ea3e757538832e12d7d13d949. It
> > breaks one of my scripts that I use to semi-automatically determine
> > recipents for patch series.
> >
> > It works as follows:
> >
> >         $ batch-add-recipents audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
> >         #!/bin/sh
> >
> >         addrecipent \
> >         -t "Rob Herring <robh@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
> >         -t "Krzysztof Kozlowski <krzk+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
> >         -t "Conor Dooley <conor+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
> >         -t "Neil Armstrong <neil.armstrong@linaro.org>" $(: maintainer:ARM/Amlogic Meson SoC support) \
> >         -t "Kevin Hilman <khilman@baylibre.com>" $(: maintainer:ARM/Amlogic Meson SoC support) \
> >         -c "Jerome Brunet <jbrunet@baylibre.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
> >         -c "Martin Blumenstingl <martin.blumenstingl@googlemail.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
> >         -t "Liam Girdwood <lgirdwood@gmail.com>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
> >         -t "Mark Brown <broonie@kernel.org>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
> >         -t "Jaroslav Kysela <perex@perex.cz>" $(: maintainer:SOUND) \
> >         -t "Takashi Iwai <tiwai@suse.com>" $(: maintainer:SOUND) \
> >         -c "devicetree@vger.kernel.org" $(: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
> >         -c "linux-arm-kernel@lists.infradead.org" $(: moderated list:ARM/Amlogic Meson SoC support) \
> >         -c "linux-amlogic@lists.infradead.org" $(: open list:ARM/Amlogic Meson SoC support) \
> >         -c "linux-kernel@vger.kernel.org" $(: open list) \
> >         -c "linux-sound@vger.kernel.org" $(: open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
> >         audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
> 
> Hey, that looks familiar ;-)
> 
> > the output is usually redirected to a file that I edit before running
> > it. The additional line in the output of
> >
> >         scripts/get_maintainer.pl audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
> >
> > with your change breaks that script.
> 
> You forgot to list the additional output?
> 
> I gave it a try with my script, and with one of my own patches.
> Example additional output is:
> 
>      --cc "ARM/Microchip" $(: AT91] SoC support status: Supported \
>     --cc "QAT DRIVER status: Supported \
>     --cc "ARM/ASPEED MACHINE SUPPORT status: Supported \
>     --cc "MELEXIS MLX90614 DRIVER status: Supported \
>     --cc "ARM/NUVOTON MA35 ARCHITECTURE status: Supported \
>     --cc "ARM/RISC-V/RENESAS ARCHITECTURE status: Supported \

Is that really your output? No closing ) in the first line and no
closing " in the 5 last?

For me it's worse(?), I get:

	$ batch-add-recipents audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
	#!/bin/sh

	addrecipent \
	-t "Rob Herring <robh@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
	-t "Krzysztof Kozlowski <krzk+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
	-t "Conor Dooley <conor+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
	-t "Neil Armstrong <neil.armstrong@linaro.org>" $(: maintainer:ARM/Amlogic Meson SoC support) \
	-t "Kevin Hilman <khilman@baylibre.com>" $(: maintainer:ARM/Amlogic Meson SoC support) \
	-c "Jerome Brunet <jbrunet@baylibre.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
	-c "Martin Blumenstingl <martin.blumenstingl@googlemail.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
	-t "Liam Girdwood <lgirdwood@gmail.com>" $(: maintainer:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
	-t "Mark Brown <broonie@kernel.org>" $(: maintainer:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
	-t "Jaroslav Kysela <perex@perex.cz>" $(: maintainer:SOUND) \
	-t "Takashi Iwai <tiwai@suse.com>" $(: maintainer:SOUND) \
	-c "devicetree@vger.kernel.org" $(: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
	-c "linux-arm-kernel@lists.infradead.org" $(: moderated list:ARM/Amlogic Meson SoC support) \
	-c "linux-amlogic@lists.infradead.org" $(: open list:ARM/Amlogic Meson SoC support) \
	-c "linux-kernel@vger.kernel.org" $(: open list) \
	-c "linux-sound@vger.kernel.org" $(: open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
	Failed to parse "SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEMENT (ASoC) status: Supported
	" at -e line 6, <> line 17.

.

To fix I added

	next if /^[^@]*status:/;

to the perl script that parses get_maintainer.pl's output.
 
> Iff this extra output is good to have, why not include it in the comment
> next to the existing entries with the email addresses, so it will be
> handled automatically by all scripting on top?

That would be great.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Geert Uytterhoeven]

Hi Uwe,

On Tue, 11 Feb 2025 at 16:09, Uwe Kleine-König
<u.kleine-koenig@baylibre.com> wrote:
> On Tue, Feb 11, 2025 at 11:48:13AM +0100, Geert Uytterhoeven wrote:
> > On Tue, 11 Feb 2025 at 11:32, Uwe Kleine-König
> > <u.kleine-koenig@baylibre.com> wrote:
> > > On Mon, Feb 03, 2025 at 12:13:16PM +0100, Vlastimil Babka wrote:
> > > > The subsystem status 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 (i.e. typically, Orphan subsystems have no
> > > >   maintainers)
> > > >
> > > > - the Supported status means that someone is paid for maintaining, but
> > > >   it is reported as "supporter" for all the maintainers, which can be
> > > >   incorrect. People have been also confused about what "supporter"
> > > >   means.
> > > >
> > > > This patch introduces a new --substatus option and functionality aimed
> > > > to report the subsystem status separately, without adjusting the
> > > > reported maintainer role. After the e-mails are output, the status of
> > > > subsystems will follow, for example:
> > > >
> > > > ...
> > > > linux-kernel@vger.kernel.org (open list:LIBRARY CODE)
> > > > LIBRARY CODE status: Supported
> > > >
> > > > In order to allow replacing the role rewriting seamlessly, the new
> > > > option works as follows:
> > > >
> > > > - it is automatically enabled when --email and --role are enabled
> > > >   (the defaults include --email and --rolestats which implies --role)
> > > >
> > > > - usages with --norolestats e.g. for git's --cc-cmd will thus need no
> > > >   adjustments
> > > >
> > > > - the most common Maintained status is not reported at all, to reduce
> > > >   unnecessary noise
> > > >
> > > > - THE REST catch-all section (contains lkml) status is not reported
> > > >
> > > > - the existing --subsystem and --status options are unaffected so their
> > > >   users will need no adjustments
> > > >
> > > > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> > >
> > > This patch is in next as c1565b6f7b53ea1ea3e757538832e12d7d13d949. It
> > > breaks one of my scripts that I use to semi-automatically determine
> > > recipents for patch series.
> > >
> > > It works as follows:
> > >
> > >         $ batch-add-recipents audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
> > >         #!/bin/sh
> > >
> > >         addrecipent \
> > >         -t "Rob Herring <robh@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
> > >         -t "Krzysztof Kozlowski <krzk+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
> > >         -t "Conor Dooley <conor+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
> > >         -t "Neil Armstrong <neil.armstrong@linaro.org>" $(: maintainer:ARM/Amlogic Meson SoC support) \
> > >         -t "Kevin Hilman <khilman@baylibre.com>" $(: maintainer:ARM/Amlogic Meson SoC support) \
> > >         -c "Jerome Brunet <jbrunet@baylibre.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
> > >         -c "Martin Blumenstingl <martin.blumenstingl@googlemail.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
> > >         -t "Liam Girdwood <lgirdwood@gmail.com>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
> > >         -t "Mark Brown <broonie@kernel.org>" $(: supporter:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
> > >         -t "Jaroslav Kysela <perex@perex.cz>" $(: maintainer:SOUND) \
> > >         -t "Takashi Iwai <tiwai@suse.com>" $(: maintainer:SOUND) \
> > >         -c "devicetree@vger.kernel.org" $(: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
> > >         -c "linux-arm-kernel@lists.infradead.org" $(: moderated list:ARM/Amlogic Meson SoC support) \
> > >         -c "linux-amlogic@lists.infradead.org" $(: open list:ARM/Amlogic Meson SoC support) \
> > >         -c "linux-kernel@vger.kernel.org" $(: open list) \
> > >         -c "linux-sound@vger.kernel.org" $(: open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
> > >         audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
> >
> > Hey, that looks familiar ;-)
> >
> > > the output is usually redirected to a file that I edit before running
> > > it. The additional line in the output of
> > >
> > >         scripts/get_maintainer.pl audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
> > >
> > > with your change breaks that script.
> >
> > You forgot to list the additional output?
> >
> > I gave it a try with my script, and with one of my own patches.
> > Example additional output is:
> >
> >      --cc "ARM/Microchip" $(: AT91] SoC support status: Supported \
> >     --cc "QAT DRIVER status: Supported \
> >     --cc "ARM/ASPEED MACHINE SUPPORT status: Supported \
> >     --cc "MELEXIS MLX90614 DRIVER status: Supported \
> >     --cc "ARM/NUVOTON MA35 ARCHITECTURE status: Supported \
> >     --cc "ARM/RISC-V/RENESAS ARCHITECTURE status: Supported \
>
> Is that really your output? No closing ) in the first line and no
> closing " in the 5 last?

Yes it is....
As I need to delete the lines anyway, invalid syntax is irrelevant ;-)

> For me it's worse(?), I get:
>
>         $ batch-add-recipents audin-patch-v1/0001-ASoC-meson-HACK-let-AIU-export-its-clocks-through-cl.patch
>         #!/bin/sh
>
>         addrecipent \
>         -t "Rob Herring <robh@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>         -t "Krzysztof Kozlowski <krzk+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>         -t "Conor Dooley <conor+dt@kernel.org>" $(: maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>         -t "Neil Armstrong <neil.armstrong@linaro.org>" $(: maintainer:ARM/Amlogic Meson SoC support) \
>         -t "Kevin Hilman <khilman@baylibre.com>" $(: maintainer:ARM/Amlogic Meson SoC support) \
>         -c "Jerome Brunet <jbrunet@baylibre.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
>         -c "Martin Blumenstingl <martin.blumenstingl@googlemail.com>" $(: reviewer:ARM/Amlogic Meson SoC support) \
>         -t "Liam Girdwood <lgirdwood@gmail.com>" $(: maintainer:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
>         -t "Mark Brown <broonie@kernel.org>" $(: maintainer:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
>         -t "Jaroslav Kysela <perex@perex.cz>" $(: maintainer:SOUND) \
>         -t "Takashi Iwai <tiwai@suse.com>" $(: maintainer:SOUND) \
>         -c "devicetree@vger.kernel.org" $(: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) \
>         -c "linux-arm-kernel@lists.infradead.org" $(: moderated list:ARM/Amlogic Meson SoC support) \
>         -c "linux-amlogic@lists.infradead.org" $(: open list:ARM/Amlogic Meson SoC support) \
>         -c "linux-kernel@vger.kernel.org" $(: open list) \
>         -c "linux-sound@vger.kernel.org" $(: open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...) \
>         Failed to parse "SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEMENT (ASoC) status: Supported
>         " at -e line 6, <> line 17.

Oops...

My version is also not perfect. I'm used to doing manual adjustments...

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

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

[Vlastimil Babka]

On 2/3/25 12:13, Vlastimil Babka wrote:
> The subsystem status 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 (i.e. typically, Orphan subsystems have no
>   maintainers)
> 
> - the Supported status means that someone is paid for maintaining, but
>   it is reported as "supporter" for all the maintainers, which can be
>   incorrect. People have been also confused about what "supporter"
>   means.
> 
> This patch introduces a new --substatus option and functionality aimed
> to report the subsystem status separately, without adjusting the
> reported maintainer role. After the e-mails are output, the status of
> subsystems will follow, for example:
> 
> ...
> linux-kernel@vger.kernel.org (open list:LIBRARY CODE)
> LIBRARY CODE status: Supported
> 
> In order to allow replacing the role rewriting seamlessly, the new
> option works as follows:
> 
> - it is automatically enabled when --email and --role are enabled
>   (the defaults include --email and --rolestats which implies --role)

With the following fixup, the above changes to:

- it is automatically enabled when --email and --role are enabled and the
  output is a terminal (the defaults include --email and --rolestats which
  implies --role)

----8<----
From f5523a85c742065fcb88a8aa26831f9dba9faf15 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@suse.cz>
Date: Tue, 11 Feb 2025 16:16:11 +0100
Subject: [PATCH] get_maintainer: add --substatus for reporting subsystem
 status - fix

The automatically enabled --substatus can break existing scripts that do
not disable --rolestats. Require that script output goes to a terminal
to enable it automatically.

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
 scripts/get_maintainer.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index cf902417a52c..4414194bedcf 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -317,7 +317,7 @@ $output_rolestats = 1 if ($interactive);
 $output_roles = 1 if ($output_rolestats);
 
 if (!defined $output_substatus) {
-    $output_substatus = $email && $output_roles;
+    $output_substatus = $email && $output_roles && -t STDOUT;
 }
 
 if ($sections || $letters ne "") {
@@ -1086,7 +1086,7 @@ version: $V
     --remove-duplicates => minimize duplicate email names/addresses
     --roles => show roles (role:subsystem, git-signer, list, etc...)
     --rolestats => show roles and statistics (commits/total_commits, %)
-    --substatus => show subsystem status if not Maintained (default: match --roles)"
+    --substatus => show subsystem status if not Maintained (default: match --roles when output is tty)"
     --file-emails => add email addresses found in -f file (default: 0 (off))
     --fixes => for patches, add signatures of commits with 'Fixes: <commit>' (default: 1 (on))
   --scm => print SCM tree(s) if any
-- 
2.48.1

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

[Geert Uytterhoeven]

Hi Vlastimil,

On Tue, 11 Feb 2025 at 17:01, Vlastimil Babka <vbabka@suse.cz> wrote:
> On 2/3/25 12:13, Vlastimil Babka wrote:
> > The subsystem status 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 (i.e. typically, Orphan subsystems have no
> >   maintainers)
> >
> > - the Supported status means that someone is paid for maintaining, but
> >   it is reported as "supporter" for all the maintainers, which can be
> >   incorrect. People have been also confused about what "supporter"
> >   means.
> >
> > This patch introduces a new --substatus option and functionality aimed
> > to report the subsystem status separately, without adjusting the
> > reported maintainer role. After the e-mails are output, the status of
> > subsystems will follow, for example:
> >
> > ...
> > linux-kernel@vger.kernel.org (open list:LIBRARY CODE)
> > LIBRARY CODE status: Supported
> >
> > In order to allow replacing the role rewriting seamlessly, the new
> > option works as follows:
> >
> > - it is automatically enabled when --email and --role are enabled
> >   (the defaults include --email and --rolestats which implies --role)
>
> With the following fixup, the above changes to:
>
> - it is automatically enabled when --email and --role are enabled and the
>   output is a terminal (the defaults include --email and --rolestats which
>   implies --role)
>
> ----8<----
> From f5523a85c742065fcb88a8aa26831f9dba9faf15 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Tue, 11 Feb 2025 16:16:11 +0100
> Subject: [PATCH] get_maintainer: add --substatus for reporting subsystem
>  status - fix
>
> The automatically enabled --substatus can break existing scripts that do
> not disable --rolestats. Require that script output goes to a terminal
> to enable it automatically.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>

Thanks, that fixes the issue for me.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

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

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

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 2777 bytes --]

On Wed, Feb 12, 2025 at 01:42:15PM +0100, Geert Uytterhoeven wrote:
> Hi Vlastimil,
> 
> On Tue, 11 Feb 2025 at 17:01, Vlastimil Babka <vbabka@suse.cz> wrote:
> > On 2/3/25 12:13, Vlastimil Babka wrote:
> > > The subsystem status 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 (i.e. typically, Orphan subsystems have no
> > >   maintainers)
> > >
> > > - the Supported status means that someone is paid for maintaining, but
> > >   it is reported as "supporter" for all the maintainers, which can be
> > >   incorrect. People have been also confused about what "supporter"
> > >   means.
> > >
> > > This patch introduces a new --substatus option and functionality aimed
> > > to report the subsystem status separately, without adjusting the
> > > reported maintainer role. After the e-mails are output, the status of
> > > subsystems will follow, for example:
> > >
> > > ...
> > > linux-kernel@vger.kernel.org (open list:LIBRARY CODE)
> > > LIBRARY CODE status: Supported
> > >
> > > In order to allow replacing the role rewriting seamlessly, the new
> > > option works as follows:
> > >
> > > - it is automatically enabled when --email and --role are enabled
> > >   (the defaults include --email and --rolestats which implies --role)
> >
> > With the following fixup, the above changes to:
> >
> > - it is automatically enabled when --email and --role are enabled and the
> >   output is a terminal (the defaults include --email and --rolestats which
> >   implies --role)
> >
> > ----8<----
> > From f5523a85c742065fcb88a8aa26831f9dba9faf15 Mon Sep 17 00:00:00 2001
> > From: Vlastimil Babka <vbabka@suse.cz>
> > Date: Tue, 11 Feb 2025 16:16:11 +0100
> > Subject: [PATCH] get_maintainer: add --substatus for reporting subsystem
> >  status - fix
> >
> > The automatically enabled --substatus can break existing scripts that do
> > not disable --rolestats. Require that script output goes to a terminal
> > to enable it automatically.
> >
> > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> 
> Thanks, that fixes the issue for me.
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Ditto for me (it allows me to undo the workaround I already implemented
:-)

Tested-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>

To please the regzbot, you also might want to add:

Fixes: c1565b6f7b53 ("get_maintainer: add --substatus for reporting subsystem status")
Closes: https://lore.kernel.org/all/7aodxv46lj6rthjo4i5zhhx2lybrhb4uknpej2dyz3e7im5w3w@w23bz6fx3jnn/

Thanks
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v2 2/2] get_maintainer: stop reporting subsystem status as maintainer role

[Vlastimil Babka]

After introducing the --substatus option, we can stop adjusting the
reported maintainer role by the subsystem's status.

For compatibility with the --git-chief-penguins option, keep the "chief
penguin" role.

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
 scripts/get_maintainer.pl | 21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index da7fc70f17cd8d46b45da8db0b2029bb11b25af1..cf902417a52cccfd5dd00ac7d2fe43d9f43d2528 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -1084,7 +1084,7 @@ version: $V
     --moderated => include moderated lists(s) if any (default: true)
     --s => include subscriber only list(s) if any (default: false)
     --remove-duplicates => minimize duplicate email names/addresses
-    --roles => show roles (status:subsystem, git-signer, list, etc...)
+    --roles => show roles (role:subsystem, git-signer, list, etc...)
     --rolestats => show roles and statistics (commits/total_commits, %)
     --substatus => show subsystem status if not Maintained (default: match --roles)"
     --file-emails => add email addresses found in -f file (default: 0 (off))
@@ -1298,8 +1298,9 @@ sub get_maintainer_role {
     my $start = find_starting_index($index);
     my $end = find_ending_index($index);
 
-    my $role = "unknown";
+    my $role = "maintainer";
     my $subsystem = get_subsystem_name($index);
+    my $status = "unknown";
 
     for ($i = $start + 1; $i < $end; $i++) {
 	my $tv = $typevalue[$i];
@@ -1307,23 +1308,13 @@ sub get_maintainer_role {
 	    my $ptype = $1;
 	    my $pvalue = $2;
 	    if ($ptype eq "S") {
-		$role = $pvalue;
+		$status = $pvalue;
 	    }
 	}
     }
 
-    $role = lc($role);
-    if      ($role eq "supported") {
-	$role = "supporter";
-    } elsif ($role eq "maintained") {
-	$role = "maintainer";
-    } elsif ($role eq "odd fixes") {
-	$role = "odd fixer";
-    } elsif ($role eq "orphan") {
-	$role = "orphan minder";
-    } elsif ($role eq "obsolete") {
-	$role = "obsolete minder";
-    } elsif ($role eq "buried alive in reporters") {
+    $status = lc($status);
+    if ($status eq "buried alive in reporters") {
 	$role = "chief penguin";
     }
 

-- 
2.48.1

Re: [PATCH v2 2/2] get_maintainer: stop reporting subsystem status as maintainer role

[Lorenzo Stoakes]

On Mon, Feb 03, 2025 at 12:13:17PM +0100, Vlastimil Babka wrote:
> After introducing the --substatus option, we can stop adjusting the
> reported maintainer role by the subsystem's status.
>
> For compatibility with the --git-chief-penguins option, keep the "chief
> penguin" role.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>

LGTM,

Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

Tested locally and working, so also:

Tested-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

> ---
>  scripts/get_maintainer.pl | 21 ++++++---------------
>  1 file changed, 6 insertions(+), 15 deletions(-)
>
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index da7fc70f17cd8d46b45da8db0b2029bb11b25af1..cf902417a52cccfd5dd00ac7d2fe43d9f43d2528 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -1084,7 +1084,7 @@ version: $V
>      --moderated => include moderated lists(s) if any (default: true)
>      --s => include subscriber only list(s) if any (default: false)
>      --remove-duplicates => minimize duplicate email names/addresses
> -    --roles => show roles (status:subsystem, git-signer, list, etc...)
> +    --roles => show roles (role:subsystem, git-signer, list, etc...)
>      --rolestats => show roles and statistics (commits/total_commits, %)
>      --substatus => show subsystem status if not Maintained (default: match --roles)"
>      --file-emails => add email addresses found in -f file (default: 0 (off))
> @@ -1298,8 +1298,9 @@ sub get_maintainer_role {
>      my $start = find_starting_index($index);
>      my $end = find_ending_index($index);
>
> -    my $role = "unknown";
> +    my $role = "maintainer";
>      my $subsystem = get_subsystem_name($index);
> +    my $status = "unknown";
>
>      for ($i = $start + 1; $i < $end; $i++) {
>  	my $tv = $typevalue[$i];
> @@ -1307,23 +1308,13 @@ sub get_maintainer_role {
>  	    my $ptype = $1;
>  	    my $pvalue = $2;
>  	    if ($ptype eq "S") {
> -		$role = $pvalue;
> +		$status = $pvalue;
>  	    }
>  	}
>      }
>
> -    $role = lc($role);
> -    if      ($role eq "supported") {
> -	$role = "supporter";
> -    } elsif ($role eq "maintained") {
> -	$role = "maintainer";
> -    } elsif ($role eq "odd fixes") {
> -	$role = "odd fixer";
> -    } elsif ($role eq "orphan") {
> -	$role = "orphan minder";
> -    } elsif ($role eq "obsolete") {
> -	$role = "obsolete minder";
> -    } elsif ($role eq "buried alive in reporters") {
> +    $status = lc($status);
> +    if ($status eq "buried alive in reporters") {
>  	$role = "chief penguin";
>      }
>
>
> --
> 2.48.1
>

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

[Lorenzo Stoakes]

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