[PATCH] get_maintainer: only use THE REST as a fallback

[PATCH] get_maintainer: only use THE REST as a fallback

[Konstantin Ryabitsev]

THE REST matches every file in the tree via "F: *" and "F: */", so
get_maintainer.pl currently adds linux-kernel@vger.kernel.org to every
patch, regardless of whether the touched files already belong to a
subsystem with its own mailing list.

Only add THE REST for a file when no other matching section provides a
mailing list for it. Files that match no section, or only sections
without an L: entry, still fall back to THE REST, so every patch keeps
reaching at least one public list.

Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
---
LKML has become mostly a firehose of patches that are already going to a
subsystem list. The reason is THE REST: it matches every file in the
tree, so get_maintainer.pl adds linux-kernel@vger.kernel.org to every
single patch. During the week of Oct 1-7, 2026:

  - LKML carried 13,641 messages (~1,950/day), 90% of which were also
    sent to at least one other list;
  - with ~2,100 subscribers, that is about 29 million deliveries per
    week for LKML alone.

This issue came up during the 2026 Maintainer Summit and the consensus
was that "always include linux-kernel for every patch" was never the
intent.

This patch makes THE REST a fallback as initially intended: it is only
added for a file when no other matching MAINTAINERS section provides a
mailing list for it.
---
 scripts/get_maintainer.pl | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 16b80a700d4a..966595c3a6de 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -959,6 +959,14 @@ sub get_maintainers {
 	    $tvi = $end + 1;
 	}
 
+	# THE REST matches every file, so only fall back to it when no
+	# other matching section provides a mailing list for this file.
+	my ($the_rest) = grep { get_section_name($_) eq "THE REST" } keys %hash;
+	if (defined($the_rest) &&
+	    grep { $_ != $the_rest && section_has_list($_) } keys %hash) {
+	    delete $hash{$the_rest};
+	}
+
 	foreach my $line (sort {$hash{$b} <=> $hash{$a}} keys %hash) {
 	    add_categories($line, "");
 	    if ($sections) {
@@ -1295,6 +1303,23 @@ sub find_ending_index {
     return $index;
 }
 
+sub get_section_name {
+    my ($index) = @_;
+
+    return $typevalue[find_starting_index($index)];
+}
+
+sub section_has_list {
+    my ($index) = @_;
+
+    my $start = find_starting_index($index);
+    my $end = find_ending_index($index);
+    for (my $i = $start; $i < $end; $i++) {
+	return 1 if ($typevalue[$i] =~ m/^L:/);
+    }
+    return 0;
+}
+
 sub get_subsystem_name {
     my ($index) = @_;
 

---
base-commit: a90ee4305c4a5df72c11b31dacfdc76e00fcf78a
change-id: 20261008-get-maintainer-the-rest-fallback-6655e8a648d4

Best regards,
--  
Konstantin Ryabitsev <konstantin@linuxfoundation.org>

Re: [PATCH] get_maintainer: only use THE REST as a fallback

[Jason A. Donenfeld]

Hi Konstantin,

On Thu, Oct 8, 2026 at 2:56 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> This issue came up during the 2026 Maintainer Summit and the consensus
> was that "always include linux-kernel for every patch" was never the
> intent.

Thanks for communicating this! I had always assumed the opposite,
based on what I saw happening. Glad it's been settled.

Jason

Re: [PATCH] get_maintainer: only use THE REST as a fallback

[Konstantin Ryabitsev]

On Thu, Oct 08, 2026 at 03:03:11PM +0200, Jason A. Donenfeld wrote:
> On Thu, Oct 8, 2026 at 2:56 PM Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> > This issue came up during the 2026 Maintainer Summit and the consensus
> > was that "always include linux-kernel for every patch" was never the
> > intent.
> 
> Thanks for communicating this! I had always assumed the opposite,
> based on what I saw happening. Glad it's been settled.

Note, that if we DO want to send all patches to a dedicated mailing list, this
can be accommodated, too -- just not the list with 2100 subscribers (because
it's not working). We have patches@lists.linux.dev, which was originally set
up as an archive-only dumping ground with no subscribers (by design).

If considered useful, I can update this patch to get us both worlds:

- THE REST actually works as a fallback
- patches@lists.linux.dev is included on all patches as an archival list

-K

Re: [PATCH] get_maintainer: only use THE REST as a fallback

[Matthieu Baerts]

Hi Konstantin,

On 08/10/2026 15:10, Konstantin Ryabitsev wrote:
> On Thu, Oct 08, 2026 at 03:03:11PM +0200, Jason A. Donenfeld wrote:
>> On Thu, Oct 8, 2026 at 2:56 PM Konstantin Ryabitsev
>> <konstantin@linuxfoundation.org> wrote:
>>> This issue came up during the 2026 Maintainer Summit and the consensus
>>> was that "always include linux-kernel for every patch" was never the
>>> intent.

Thank you for the patch!

>> Thanks for communicating this! I had always assumed the opposite,
>> based on what I saw happening. Glad it's been settled.
> 
> Note, that if we DO want to send all patches to a dedicated mailing list, this
> can be accommodated, too -- just not the list with 2100 subscribers (because
> it's not working). We have patches@lists.linux.dev, which was originally set
> up as an archive-only dumping ground with no subscribers (by design).
> 
> If considered useful, I can update this patch to get us both worlds:
> 
> - THE REST actually works as a fallback
> - patches@lists.linux.dev is included on all patches as an archival list

Is this list actively being used? The risk I see with this list is
having someone sending a new version of an existing patch only to this
list: this version will then be picked by tools like b4. If the
maintainer doesn't pay attention to the info messages, a wrong version
might be applied instead. Maybe b4 should catch such patches?

Or would this be required because some subsystem ML's are not on lore?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: [PATCH] get_maintainer: only use THE REST as a fallback

[Konstantin Ryabitsev]

On Thu, Oct 08, 2026 at 03:22:56PM +0200, Matthieu Baerts wrote:
> Is this list actively being used? The risk I see with this list is
> having someone sending a new version of an existing patch only to this
> list: this version will then be picked by tools like b4. If the
> maintainer doesn't pay attention to the info messages, a wrong version
> might be applied instead. Maybe b4 should catch such patches?

I'm trying to think of how this would happen. If the submitter users
get-maintainer.pl, then they should always get the correct set of lists. If
they aren't using get-maintainer.pl, then they aren't really likely to use
just the patches archive list.

If they use b4 to send the patches, then even if they do manage to mess up the
recipients, somehow, the maintainer should still be able to find it via the
change-id search.

-K

Re: [PATCH] get_maintainer: only use THE REST as a fallback

[Matthieu Baerts]

On 08/10/2026 16:05, Konstantin Ryabitsev wrote:
> On Thu, Oct 08, 2026 at 03:22:56PM +0200, Matthieu Baerts wrote:
>> Is this list actively being used? The risk I see with this list is
>> having someone sending a new version of an existing patch only to this
>> list: this version will then be picked by tools like b4. If the
>> maintainer doesn't pay attention to the info messages, a wrong version
>> might be applied instead. Maybe b4 should catch such patches?
> 
> I'm trying to think of how this would happen. If the submitter users
> get-maintainer.pl, then they should always get the correct set of lists. If
> they aren't using get-maintainer.pl, then they aren't really likely to use
> just the patches archive list.
> 
> If they use b4 to send the patches, then even if they do manage to mess up the
> recipients, somehow, the maintainer should still be able to find it via the
> change-id search.

Sorry, I meant to say: when someone is trying to discretely get a bad
version applied on purpose. For example: user A sends a v1 using
get_maintainer.pl, then user B (or A) could send a v2 (or a v1 with
other content) only to patches@lists.linux.dev. In this case, a
maintainer who wants to apply the original v1, might end-up applying the
"bad" and "hidden" patch.

Or maybe "b4" already prevents that or is clear enough when picking a
newer/different version than the given one?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: [PATCH] get_maintainer: only use THE REST as a fallback

[Jason A. Donenfeld]

On Thu, Oct 8, 2026 at 3:10 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> - THE REST actually works as a fallback
> - patches@lists.linux.dev is included on all patches as an archival list

Couldn't this list be programmatically populated? Lore is already
watching every other mailing list. Can it simply post ones to patches@
that patches@ hasn't already seen? Then we don't need to worry about
the folly of trying to teach people about another list and such.

Jason

Re: [PATCH] get_maintainer: only use THE REST as a fallback

[Jürgen Groß]

[-- Attachment #1.1.1: Type: text/plain, Size: 2038 bytes --]

On 08.10.26 14:51, Konstantin Ryabitsev wrote:
> THE REST matches every file in the tree via "F: *" and "F: */", so
> get_maintainer.pl currently adds linux-kernel@vger.kernel.org to every
> patch, regardless of whether the touched files already belong to a
> subsystem with its own mailing list.
> 
> Only add THE REST for a file when no other matching section provides a
> mailing list for it. Files that match no section, or only sections
> without an L: entry, still fall back to THE REST, so every patch keeps
> reaching at least one public list.
> 
> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> ---
> LKML has become mostly a firehose of patches that are already going to a
> subsystem list. The reason is THE REST: it matches every file in the
> tree, so get_maintainer.pl adds linux-kernel@vger.kernel.org to every
> single patch. During the week of Oct 1-7, 2026:
> 
>    - LKML carried 13,641 messages (~1,950/day), 90% of which were also
>      sent to at least one other list;
>    - with ~2,100 subscribers, that is about 29 million deliveries per
>      week for LKML alone.
> 
> This issue came up during the 2026 Maintainer Summit and the consensus
> was that "always include linux-kernel for every patch" was never the
> intent.
> 
> This patch makes THE REST a fallback as initially intended: it is only
> added for a file when no other matching MAINTAINERS section provides a
> mailing list for it.

Hmm, for me this will be a major problem.

As the Xen code maintainer I have stumbled over problematic patches which
were NOT sent to x86 or xen ML several times, which made it possible to catch
potential regressions early.

Having to subscribe to each potentially interesting ML (or using korgalore on
those) would not be my preferred workflow.

This isn't a NACK, but maybe there are others with similar interests/problems.

Or is korgalore capable of pulling ALL kernel related mails without having to
spell out the MLs explicitly?


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH] get_maintainer: only use THE REST as a fallback

[Konstantin Ryabitsev]

On Thu, Oct 08, 2026 at 03:15:03PM +0200, Jürgen Groß wrote:
> Hmm, for me this will be a major problem.
> 
> As the Xen code maintainer I have stumbled over problematic patches which
> were NOT sent to x86 or xen ML several times, which made it possible to catch
> potential regressions early.
> 
> Having to subscribe to each potentially interesting ML (or using korgalore on
> those) would not be my preferred workflow.
> 
> This isn't a NACK, but maybe there are others with similar interests/problems.
> 
> Or is korgalore capable of pulling ALL kernel related mails without having to
> spell out the MLs explicitly?

Yes, if we do add patches@lists.linux.dev as the always-on archive list, you'd
be able to run lei/korgalore to get the exact current LKML firehose by doing
something like "l:linux-kernel.vger.kernel.org OR l:patches.lists.linux.dev"
and then deduping by MID.

-K

Re: [PATCH] get_maintainer: only use THE REST as a fallback

[Jason Gunthorpe]

On Thu, Oct 08, 2026 at 03:15:03PM +0200, Jürgen Groß wrote:

> As the Xen code maintainer I have stumbled over problematic patches which
> were NOT sent to x86 or xen ML several times, which made it possible to catch
> potential regressions early.

FWIW I use lei with a File match pattern to have a 'virtual mailing list'
of areas I want to pay attention to. It catches everything no matter
where it is sent. 

Jason

Re: [PATCH] get_maintainer: only use THE REST as a fallback

[Michael S. Tsirkin]

On Thu, Oct 08, 2026 at 08:51:19AM -0400, Konstantin Ryabitsev wrote:
> THE REST matches every file in the tree via "F: *" and "F: */", so
> get_maintainer.pl currently adds linux-kernel@vger.kernel.org to every
> patch, regardless of whether the touched files already belong to a
> subsystem with its own mailing list.
> 
> Only add THE REST for a file when no other matching section provides a
> mailing list for it. Files that match no section, or only sections
> without an L: entry, still fall back to THE REST, so every patch keeps
> reaching at least one public list.
> 
> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>

Not that I mind but it sure was nice that literally every patch was on
lore. Are all subsystem lists archived on lore?
If not maybe a new lore@ list just for archival purposes?

> ---
> LKML has become mostly a firehose of patches that are already going to a
> subsystem list. The reason is THE REST: it matches every file in the
> tree, so get_maintainer.pl adds linux-kernel@vger.kernel.org to every
> single patch. During the week of Oct 1-7, 2026:
> 
>   - LKML carried 13,641 messages (~1,950/day), 90% of which were also
>     sent to at least one other list;
>   - with ~2,100 subscribers, that is about 29 million deliveries per
>     week for LKML alone.
> 
> This issue came up during the 2026 Maintainer Summit and the consensus
> was that "always include linux-kernel for every patch" was never the
> intent.
> 
> This patch makes THE REST a fallback as initially intended: it is only
> added for a file when no other matching MAINTAINERS section provides a
> mailing list for it.
> ---
>  scripts/get_maintainer.pl | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index 16b80a700d4a..966595c3a6de 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -959,6 +959,14 @@ sub get_maintainers {
>  	    $tvi = $end + 1;
>  	}
>  
> +	# THE REST matches every file, so only fall back to it when no
> +	# other matching section provides a mailing list for this file.
> +	my ($the_rest) = grep { get_section_name($_) eq "THE REST" } keys %hash;
> +	if (defined($the_rest) &&
> +	    grep { $_ != $the_rest && section_has_list($_) } keys %hash) {
> +	    delete $hash{$the_rest};
> +	}
> +
>  	foreach my $line (sort {$hash{$b} <=> $hash{$a}} keys %hash) {
>  	    add_categories($line, "");
>  	    if ($sections) {
> @@ -1295,6 +1303,23 @@ sub find_ending_index {
>      return $index;
>  }
>  
> +sub get_section_name {
> +    my ($index) = @_;
> +
> +    return $typevalue[find_starting_index($index)];
> +}
> +
> +sub section_has_list {
> +    my ($index) = @_;
> +
> +    my $start = find_starting_index($index);
> +    my $end = find_ending_index($index);
> +    for (my $i = $start; $i < $end; $i++) {
> +	return 1 if ($typevalue[$i] =~ m/^L:/);
> +    }
> +    return 0;
> +}
> +
>  sub get_subsystem_name {
>      my ($index) = @_;
>  
> 
> ---
> base-commit: a90ee4305c4a5df72c11b31dacfdc76e00fcf78a
> change-id: 20261008-get-maintainer-the-rest-fallback-6655e8a648d4
> 
> Best regards,
> --  
> Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> 

Re: [PATCH] get_maintainer: only use THE REST as a fallback

[Petr Pavlu]

On 10/8/26 2:51 PM, Konstantin Ryabitsev wrote:
> THE REST matches every file in the tree via "F: *" and "F: */", so
> get_maintainer.pl currently adds linux-kernel@vger.kernel.org to every
> patch, regardless of whether the touched files already belong to a
> subsystem with its own mailing list.
> 
> Only add THE REST for a file when no other matching section provides a
> mailing list for it. Files that match no section, or only sections
> without an L: entry, still fall back to THE REST, so every patch keeps
> reaching at least one public list.
> 
> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> ---
> LKML has become mostly a firehose of patches that are already going to a
> subsystem list. The reason is THE REST: it matches every file in the
> tree, so get_maintainer.pl adds linux-kernel@vger.kernel.org to every
> single patch. During the week of Oct 1-7, 2026:
> 
>   - LKML carried 13,641 messages (~1,950/day), 90% of which were also
>     sent to at least one other list;
>   - with ~2,100 subscribers, that is about 29 million deliveries per
>     week for LKML alone.
> 
> This issue came up during the 2026 Maintainer Summit and the consensus
> was that "always include linux-kernel for every patch" was never the
> intent.
> 
> This patch makes THE REST a fallback as initially intended: it is only
> added for a file when no other matching MAINTAINERS section provides a
> mailing list for it.

Documentation/process/submitting-patches.rst currently says:

| linux-kernel@vger.kernel.org should be used by default for all patches, but the
| volume on that list has caused a number of developers to tune it out.  Please
| do not spam unrelated lists and unrelated people, though.

If the behavior of scripts/get_maintainer.pl is changed, it would be
good to update this documentation accordingly, possibly by simply
reverting commit 77167b966b7e ("docs: submitting-patches: clarify the
role of LKML").

-- 
Thanks,
Petr

Re: [PATCH] get_maintainer: only use THE REST as a fallback

[Konstantin Ryabitsev]

On Thu, Oct 08, 2026 at 03:39:53PM +0200, Petr Pavlu wrote:
> Documentation/process/submitting-patches.rst currently says:
> 
> | linux-kernel@vger.kernel.org should be used by default for all patches, but the
> | volume on that list has caused a number of developers to tune it out.  Please
> | do not spam unrelated lists and unrelated people, though.
> 
> If the behavior of scripts/get_maintainer.pl is changed, it would be
> good to update this documentation accordingly, possibly by simply
> reverting commit 77167b966b7e ("docs: submitting-patches: clarify the
> role of LKML").

Yes, I'm happy to include this edit in v2.

-K

Re: [PATCH] get_maintainer: only use THE REST as a fallback

[Joe Perches]

On Thu, 2026-10-08 at 08:51 -0400, Konstantin Ryabitsev wrote:
> THE REST matches every file in the tree via "F: *" and "F: */", so
> get_maintainer.pl currently adds [linux-kernel@vger.kernel.org] every
> patch, regardless of whether the touched files already belong to a
> subsystem with its own mailing list.

Perhaps it's sensible to use a fallback email address only
when get_maintainer produces no email address and remove
the "THE REST" entry altogether.

> Only add THE REST for a file when no other matching section provides a
> mailing list for it. Files that match no section, or only sections
> without an L: entry, still fall back to THE REST, so every patch keeps
> reaching at least one public list.

Public is an interesting word choice.
There are subscriber-only mailing lists that may not be public.

$ git grep -i subscribers-only MAINTAINERS
MAINTAINERS:L:  acrn-dev@lists.projectacrn.org (subscribers-only)
MAINTAINERS:L:  openwrt-devel@lists.openwrt.org (subscribers-only)
MAINTAINERS:L:  ltp@lists.linux.it (subscribers-only)
MAINTAINERS:L:  openvpn-devel@lists.sourceforge.net (subscribers-only)
MAINTAINERS:L:  linux-parport@lists.infradead.org (subscribers-only)
MAINTAINERS:L:  linuxpps@ml.enneenne.com (subscribers-only)
MAINTAINERS:L:  pvrusb2@isely.net       (subscribers-only)
MAINTAINERS:L:  sdricohcs-devel@lists.sourceforge.net (subscribers-only)
MAINTAINERS:L:  squashfs-devel@lists.sourceforge.net (subscribers-only)
MAINTAINERS:L:  tlan-devel@lists.sourceforge.net (subscribers-only)
MAINTAINERS:L:  tomoyo-users_en@lists.sourceforge.net (subscribers-only, English language)
MAINTAINERS:L:  tomoyo-users_ja@lists.sourceforge.net (subscribers-only, Japanese language)

If the desire is to provide a [PATCH] only review style list
where lore does not have to send emails to subscribers perhaps
perhap use an aggregating / deduplicating mechanism to lore
for all patches sent to kernel.org.

Though there are what seems to be non-kernel related lists on
lore and that's likely an issue too.