[PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Konstantin Ryabitsev]

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 series 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 that get_maintainer.pl would actually output for it.
Patch 2 updates submitting-patches.rst, which currently tells submitters
to send every patch to LKML.

Several v1 reviewers asked for a catch-all list that would keep carrying
every patch for those who want to follow all kernel development. That
is a worthwhile discussion, but it is separate from this series, which
only restores THE REST to its original role.

Translation maintainers are Cc'd because the it_IT, ja_JP, sp_SP, zh_CN
and zh_TW versions of submitting-patches.rst carry the same "send every
patch to LKML" advice and will need a follow-up update once the English
text is settled.

---
Changes in v2:
- Don't count subscribers-only lists (or moderated lists with
  --no-moderated) as a destination, since get_maintainer.pl doesn't
  output them; v1 sent patches to e.g. fs/squashfs/ to no list at all
- Add submitting-patches.rst update describing LKML as the list of last
  resort (Petr Pavlu)
- Rebase on v7.3
- Link to v1: https://patch.msgid.link/20261008-get-maintainer-the-rest-fallback-v1-1-7d26d0b7aa34@linuxfoundation.org

---
Konstantin Ryabitsev (2):
      get_maintainer: only use THE REST as a fallback
      docs: submitting-patches: make LKML a list of last resort again

 Documentation/process/submitting-patches.rst |  9 ++++--
 scripts/get_maintainer.pl                    | 43 ++++++++++++++++++++++++++++
 2 files changed, 49 insertions(+), 3 deletions(-)
---
base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
base-tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
change-id: 20261008-get-maintainer-the-rest-fallback-6655e8a648d4

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

[PATCH v2 1/2] 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 that get_maintainer.pl would actually output. Lists marked
"subscribers-only" are omitted unless --s is given, and lists marked
"moderated" are omitted with --no-moderated, so such lists don't count
as a destination in those cases. Files that match no section, or only
sections without such a list, still fall back to THE REST, so every
patch keeps reaching at least one known-public mailing list.

Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
---
 scripts/get_maintainer.pl | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 16b80a700d4a..265245e568c6 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -959,6 +959,15 @@ 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
+	# that we would actually output with the current options.
+	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 +1304,40 @@ 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++) {
+	next if ($typevalue[$i] !~ m/^L:\s*(.*)/);
+	my $list_additional = "";
+	if ($1 =~ m/[^\s]+\s+(.*)$/) {
+	    $list_additional = $1;
+	}
+	return 1 if (list_is_selected($list_additional));
+    }
+    return 0;
+}
+
+# Must match the list selection in add_categories()
+sub list_is_selected {
+    my ($list_additional) = @_;
+
+    if ($list_additional =~ m/subscribers-only/) {
+	return $email_subscriber_list;
+    } elsif ($list_additional =~ m/moderated/) {
+	return $email_list && $email_moderated_list;
+    }
+    return $email_list;
+}
+
 sub get_subsystem_name {
     my ($index) = @_;
 

-- 
2.55.0

Re: [PATCH v2 1/2] get_maintainer: only use THE REST as a fallback

[Joe Perches]

On 2026-10-20 08:35, 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 that get_maintainer.pl would actually output. Lists marked
> "subscribers-only" are omitted unless --s is given, and lists marked
> "moderated" are omitted with --no-moderated, so such lists don't count
> as a destination in those cases. Files that match no section, or only
> sections without such a list, still fall back to THE REST, so every
> patch keeps reaching at least one known-public mailing list.
> 
> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> ---

I don't disagree that this is useful but v2: no changelog

Perhaps there's a simpler and more generic mechanism.  I'll play with it 
for a couple days.

Re: [PATCH v2 1/2] get_maintainer: only use THE REST as a fallback

[Konstantin Ryabitsev]

On Tue, Oct 20, 2026 at 08:47:01AM -0700, Joe Perches wrote:
> > Only add THE REST for a file when no other matching section provides a
> > mailing list that get_maintainer.pl would actually output. Lists marked
> > "subscribers-only" are omitted unless --s is given, and lists marked
> > "moderated" are omitted with --no-moderated, so such lists don't count
> > as a destination in those cases. Files that match no section, or only
> > sections without such a list, still fall back to THE REST, so every
> > patch keeps reaching at least one known-public mailing list.
> > 
> > Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> > ---
> 
> I don't disagree that this is useful but v2: no changelog
> 
> Perhaps there's a simpler and more generic mechanism.  I'll play with it for
> a couple days.

It's like to convey the sense of urgency -- with the amount of patches,
automated reviews, and follow-ups being sent daily, having all of them land on
LKML and delivered to 2000+ subscribers... is not sustainable. At this point,
I'm very close to outright banning subscriptions from gmail, outlook and yahoo
addresses. Not sending every single patch to the LKML is a better way to deal
with this.

-K

Re: [PATCH v2 1/2] get_maintainer: only use THE REST as a fallback

[Joe Perches]

On 2026-10-20 08:52, Konstantin Ryabitsev wrote:
> On Tue, Oct 20, 2026 at 08:47:01AM -0700, Joe Perches wrote:
>> > Only add THE REST for a file when no other matching section provides a
>> > mailing list that get_maintainer.pl would actually output. Lists marked
>> > "subscribers-only" are omitted unless --s is given, and lists marked
>> > "moderated" are omitted with --no-moderated, so such lists don't count
>> > as a destination in those cases. Files that match no section, or only
>> > sections without such a list, still fall back to THE REST, so every
>> > patch keeps reaching at least one known-public mailing list.
>> >
>> > Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
>> > ---
>> 
>> I don't disagree that this is useful but v2: no changelog
>> 
>> Perhaps there's a simpler and more generic mechanism.  I'll play with 
>> it for
>> a couple days.
> 
> It's like to convey the sense of urgency -- with the amount of patches,
> automated reviews, and follow-ups being sent daily, having all of them 
> land on
> LKML and delivered to 2000+ subscribers... is not sustainable. At this 
> point,
> I'm very close to outright banning subscriptions from gmail, outlook 
> and yahoo
> addresses. Not sending every single patch to the LKML is a better way 
> to deal
> with this.

No worries.
Apply it and I might deal with later.

[PATCH v2 2/2] docs: submitting-patches: make LKML a list of last resort again

[Konstantin Ryabitsev]

Commit 77167b966b7e ("docs: submitting-patches: clarify the role of
LKML") changed the documentation to say that all patches should be sent
to LKML by default, because get_maintainer.pl always suggested it.

Now that get_maintainer.pl only falls back to THE REST when no other
matching section provides a mailing list, update the documentation to
match: send patches to the subsystem-specific list, and use LKML only
when there isn't one.

Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
---
 Documentation/process/submitting-patches.rst | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 7ae79452e1b4..b4a2750599a7 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -239,9 +239,12 @@ patches as arguments to scripts/get_maintainer.pl).  If you cannot find a
 maintainer for the subsystem you are working on, Andrew Morton
 (akpm@linux-foundation.org) serves as a maintainer of last resort.
 
-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.
+You should also normally choose at least one mailing list to receive a copy of
+your patch set.  Look in the MAINTAINERS file for a subsystem-specific list;
+your patch will probably get more attention there.
+linux-kernel@vger.kernel.org functions as a list of last resort for patches
+that do not have a subsystem-specific list.  Please do not spam unrelated lists
+and unrelated people, though.
 
 Many kernel-related lists are hosted at kernel.org; you can find a list
 of them at https://subspace.kernel.org.  There are kernel-related lists

-- 
2.55.0

Re: [PATCH v2 2/2] docs: submitting-patches: make LKML a list of last resort again

[Randy Dunlap]

On 10/20/26 8:35 AM, Konstantin Ryabitsev wrote:
> Commit 77167b966b7e ("docs: submitting-patches: clarify the role of
> LKML") changed the documentation to say that all patches should be sent
> to LKML by default, because get_maintainer.pl always suggested it.
> 
> Now that get_maintainer.pl only falls back to THE REST when no other
> matching section provides a mailing list, update the documentation to
> match: send patches to the subsystem-specific list, and use LKML only
> when there isn't one.
> 
> Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> ---
>  Documentation/process/submitting-patches.rst | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index 7ae79452e1b4..b4a2750599a7 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -239,9 +239,12 @@ patches as arguments to scripts/get_maintainer.pl).  If you cannot find a
>  maintainer for the subsystem you are working on, Andrew Morton
>  (akpm@linux-foundation.org) serves as a maintainer of last resort.
>  
> -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.
> +You should also normally choose at least one mailing list to receive a copy of
> +your patch set.  Look in the MAINTAINERS file for a subsystem-specific list;
> +your patch will probably get more attention there.
> +linux-kernel@vger.kernel.org functions as a list of last resort for patches
> +that do not have a subsystem-specific list.  Please do not spam unrelated lists
> +and unrelated people, though.
>  
>  Many kernel-related lists are hosted at kernel.org; you can find a list
>  of them at https://subspace.kernel.org.  There are kernel-related lists
> 

Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.

-- 
~Randy

Re: [PATCH v2 2/2] docs: submitting-patches: make LKML a list of last resort again

[Krzysztof Kozlowski]

On 20/10/2026 17:35, Konstantin Ryabitsev wrote:
> Commit 77167b966b7e ("docs: submitting-patches: clarify the role of
> LKML") changed the documentation to say that all patches should be sent
> to LKML by default, because get_maintainer.pl always suggested it.
> 
> Now that get_maintainer.pl only falls back to THE REST when no other
> matching section provides a mailing list, update the documentation to
> match: send patches to the subsystem-specific list, and use LKML only
> when there isn't one.
> 
> Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH v2 2/2] docs: submitting-patches: make LKML a list of last resort again

[Greg KH]

On Tue, Oct 20, 2026 at 11:35:26AM -0400, Konstantin Ryabitsev wrote:
> Commit 77167b966b7e ("docs: submitting-patches: clarify the role of
> LKML") changed the documentation to say that all patches should be sent
> to LKML by default, because get_maintainer.pl always suggested it.
> 
> Now that get_maintainer.pl only falls back to THE REST when no other
> matching section provides a mailing list, update the documentation to
> match: send patches to the subsystem-specific list, and use LKML only
> when there isn't one.
> 
> Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> ---
>  Documentation/process/submitting-patches.rst | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH v2 2/2] docs: submitting-patches: make LKML a list of last resort again

[Lee Jones]

On Tue, 20 Oct 2026, Konstantin Ryabitsev wrote:

> Commit 77167b966b7e ("docs: submitting-patches: clarify the role of
> LKML") changed the documentation to say that all patches should be sent
> to LKML by default, because get_maintainer.pl always suggested it.
> 
> Now that get_maintainer.pl only falls back to THE REST when no other
> matching section provides a mailing list, update the documentation to
> match: send patches to the subsystem-specific list, and use LKML only
> when there isn't one.
> 
> Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> ---
>  Documentation/process/submitting-patches.rst | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index 7ae79452e1b4..b4a2750599a7 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -239,9 +239,12 @@ patches as arguments to scripts/get_maintainer.pl).  If you cannot find a
>  maintainer for the subsystem you are working on, Andrew Morton
>  (akpm@linux-foundation.org) serves as a maintainer of last resort.
>  
> -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.
> +You should also normally choose at least one mailing list to receive a copy of
> +your patch set.  Look in the MAINTAINERS file for a subsystem-specific list;
> +your patch will probably get more attention there.
> +linux-kernel@vger.kernel.org functions as a list of last resort for patches
> +that do not have a subsystem-specific list.  Please do not spam unrelated lists
> +and unrelated people, though.
>  
>  Many kernel-related lists are hosted at kernel.org; you can find a list
>  of them at https://subspace.kernel.org.  There are kernel-related lists

Makes sense.  Banning Gmail addresses would be less than ideal.

Reviewed-by: Lee Jones <lee@kernel.org>

-- 
Lee Jones

Re: [PATCH v2 2/2] docs: submitting-patches: make LKML a list of last resort again

[Jiri Kosina]

On Tue, 20 Oct 2026, Konstantin Ryabitsev wrote:

> Commit 77167b966b7e ("docs: submitting-patches: clarify the role of
> LKML") changed the documentation to say that all patches should be sent
> to LKML by default, because get_maintainer.pl always suggested it.
> 
> Now that get_maintainer.pl only falls back to THE REST when no other
> matching section provides a mailing list, update the documentation to
> match: send patches to the subsystem-specific list, and use LKML only
> when there isn't one.
> 
> Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>

Acked-by: Jiri Kosina <jkosina@suse.com>

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Joe Perches]

On 2026-10-20 08:35, Konstantin Ryabitsev wrote:
> 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.

That's not actually true.

Lkml was the default mailing list and other lists were specific to their 
interests.

> This series 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 that get_maintainer.pl would actually output for it.

> Patch 2 updates submitting-patches.rst, which currently tells 
> submitters
> to send every patch to LKML.

Which was the documented and then desired behavior.

No worries, things change.

I too stopped subscribing to lkml a long while ago.

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Theodore Tso]

On Tue, Oct 20, 2026 at 08:53:04AM -0500, Joe Perches 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.
> 
> That's not actually true.
> 
> Lkml was the default mailing list and other lists were specific to their
> interests.

Historical practice for decades before the change was made that plenty
of patches only went to the subsystem list (e.g., linux-ext4,
linux-scsi) and it was *never* intentional that LKML was supposed to
be cc'ed for all patches.  That didn't match historical behavior, and
as far as I know no one was asking for that change.  If someone
managed to slip that into submitting-patches, that was either a
mistake by the submitters or the people reviewing the change.

						- Ted

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Geert Uytterhoeven]

On Tue, 20 Oct 2026 at 20:52, Theodore Tso <tytso@mit.edu> wrote:
> On Tue, Oct 20, 2026 at 08:53:04AM -0500, Joe Perches 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.
> >
> > That's not actually true.
> >
> > Lkml was the default mailing list and other lists were specific to their
> > interests.
>
> Historical practice for decades before the change was made that plenty
> of patches only went to the subsystem list (e.g., linux-ext4,
> linux-scsi) and it was *never* intentional that LKML was supposed to
> be cc'ed for all patches.  That didn't match historical behavior, and
> as far as I know no one was asking for that change.  If someone
> managed to slip that into submitting-patches, that was either a
> mistake by the submitters or the people reviewing the change.

Historically, not all subsystem mailing lists were as well-archived
as lkml.  Nowadays, as long as a patch ends up on lore, it's fine.

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 0/2] get_maintainer: stop sending every patch to LKML

[Weijie Yuan]

On 2026-10-20 11:35:24 -0400, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:

> 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 series 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 that get_maintainer.pl would actually output for it.
> Patch 2 updates submitting-patches.rst, which currently tells submitters
> to send every patch to LKML.
> 
> Several v1 reviewers asked for a catch-all list that would keep carrying
> every patch for those who want to follow all kernel development. That
> is a worthwhile discussion, but it is separate from this series, which
> only restores THE REST to its original role.
> 
> Translation maintainers are Cc'd because the it_IT, ja_JP, sp_SP, zh_CN
> and zh_TW versions of submitting-patches.rst carry the same "send every
> patch to LKML" advice and will need a follow-up update once the English
> text is settled.

Thanks. Added to the todo list.

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Konstantin Ryabitsev]

On Tue, Oct 20, 2026 at 11:35:24AM -0400, Konstantin Ryabitsev wrote:
> 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 series 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 that get_maintainer.pl would actually output for it.
> Patch 2 updates submitting-patches.rst, which currently tells submitters
> to send every patch to LKML.

Linus, it looks like everyone is on board with this change, but it never made
it into any pull request. Will you consider merging this one directly for 7.4
rc-1? This ought to do it:

    b4 shazam -S 20261020-get-maintainer-the-rest-fallback-v2-0-162aea473488@linuxfoundation.org

With the ever-increasing volume of patches sent in and Gmail's obtuse "you're
sending us too much mail, back off" attitude, this is becoming urgent.

Thanks,
-K

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[David Laight]

On Tue, 20 Oct 2026 11:35:24 -0400
Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

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

That sort of implies that 2100 people are happy to receive all the
patch emails.
Take them away and there won't be much left.
OTOH you can't subscribe a gmail address - you miss most of the emails.

> 
> 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 series 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 that get_maintainer.pl would actually output for it.
> Patch 2 updates submitting-patches.rst, which currently tells submitters
> to send every patch to LKML.

Hmmm....

That means that changes that misuse standard functions (like min_t) won't
be spotted because they are hidden from anyone who might just spot from the
subject that something odd might be going on.

David

> 
> Several v1 reviewers asked for a catch-all list that would keep carrying
> every patch for those who want to follow all kernel development. That
> is a worthwhile discussion, but it is separate from this series, which
> only restores THE REST to its original role.
> 
> Translation maintainers are Cc'd because the it_IT, ja_JP, sp_SP, zh_CN
> and zh_TW versions of submitting-patches.rst carry the same "send every
> patch to LKML" advice and will need a follow-up update once the English
> text is settled.
> 
> ---
> Changes in v2:
> - Don't count subscribers-only lists (or moderated lists with
>   --no-moderated) as a destination, since get_maintainer.pl doesn't
>   output them; v1 sent patches to e.g. fs/squashfs/ to no list at all
> - Add submitting-patches.rst update describing LKML as the list of last
>   resort (Petr Pavlu)
> - Rebase on v7.3
> - Link to v1: https://patch.msgid.link/20261008-get-maintainer-the-rest-fallback-v1-1-7d26d0b7aa34@linuxfoundation.org
> 
> ---
> Konstantin Ryabitsev (2):
>       get_maintainer: only use THE REST as a fallback
>       docs: submitting-patches: make LKML a list of last resort again
> 
>  Documentation/process/submitting-patches.rst |  9 ++++--
>  scripts/get_maintainer.pl                    | 43 ++++++++++++++++++++++++++++
>  2 files changed, 49 insertions(+), 3 deletions(-)
> ---
> base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
> base-tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> change-id: 20261008-get-maintainer-the-rest-fallback-6655e8a648d4
> 
> Best regards,
> --  
> Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> 
> 

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Konstantin Ryabitsev]

On Mon, Nov 02, 2026 at 09:32:06AM +0000, David Laight wrote:
> > 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.
> 
> That sort of implies that 2100 people are happy to receive all the
> patch emails.

Doesn't really matter, since those who are at gmail.com aren't really
receiving "all the patch emails" anyway and they are impacting everyone else.
Gmail is simply not usable for high-volume mailing list traffic.

There are other, better ways to get all patches that doesn't involve
subscribing to SMTP deliveries.

-K

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Rafael J. Wysocki (Intel)]

On Mon, Nov 2, 2026 at 3:12 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> On Mon, Nov 02, 2026 at 09:32:06AM +0000, David Laight wrote:
> > > 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.
> >
> > That sort of implies that 2100 people are happy to receive all the
> > patch emails.
>
> Doesn't really matter, since those who are at gmail.com aren't really
> receiving "all the patch emails" anyway and they are impacting everyone else.
> Gmail is simply not usable for high-volume mailing list traffic.
>
> There are other, better ways to get all patches that doesn't involve
> subscribing to SMTP deliveries.

So it occurred to me that it might be actually better to stop sending
messages directly to LKML subscribers and only make it available for
download somewhere and as a Lore archive.

Is there really anyone depending on receiving all of the LKML traffic every day?

Rafael

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Jonathan Corbet]

"Rafael J. Wysocki (Intel)" <rafael@kernel.org> writes:

> So it occurred to me that it might be actually better to stop sending
> messages directly to LKML subscribers and only make it available for
> download somewhere and as a Lore archive.
>
> Is there really anyone depending on receiving all of the LKML traffic every day?

* raises hand

Some of us crazy people really do depend on it, yes.

jon

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Rafael J. Wysocki (Intel)]

On Mon, Nov 2, 2026 at 3:34 PM Jonathan Corbet <corbet@lwn.net> wrote:
>
> "Rafael J. Wysocki (Intel)" <rafael@kernel.org> writes:
>
> > So it occurred to me that it might be actually better to stop sending
> > messages directly to LKML subscribers and only make it available for
> > download somewhere and as a Lore archive.
> >
> > Is there really anyone depending on receiving all of the LKML traffic every day?
>
> * raises hand
>
> Some of us crazy people really do depend on it, yes.

Exceptions would be straightforward to make though I suppose.

So really my question would be how many people there are who depend on
receiving all of the LKML traffic every day via SMTP.  And I honestly
think that not everybody subscribed to it.  Probably not even 10% of
those people.

Rafael

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Sean Christopherson]

On Mon, Nov 02, 2026, Rafael J. Wysocki (Intel) wrote:
> On Mon, Nov 2, 2026 at 3:34 PM Jonathan Corbet <corbet@lwn.net> wrote:
> >
> > "Rafael J. Wysocki (Intel)" <rafael@kernel.org> writes:
> >
> > > So it occurred to me that it might be actually better to stop sending
> > > messages directly to LKML subscribers and only make it available for
> > > download somewhere and as a Lore archive.
> > >
> > > Is there really anyone depending on receiving all of the LKML traffic every day?
> >
> > * raises hand
> >
> > Some of us crazy people really do depend on it, yes.

+1, e.g. it's how I found out about this proposed change.  FWIW, I don't actually
need (or want) to receive *all* LKML traffic; I probably only truly consume less
than 1% of the mails, via heavy filtering.  But AFAIK, there isn't an alternative
way to arbitrarily choose what traffic is important to me.

> Exceptions would be straightforward to make though I suppose.
> 
> So really my question would be how many people there are who depend on
> receiving all of the LKML traffic every day via SMTP.  And I honestly
> think that not everybody subscribed to it.  Probably not even 10% of
> those people.

There are quite a few subsystems that use linux-kernel@vger.kernel.org as their
one and only list, including (almost?) all of the subsystems that are routed through
the tip tree (x86@ isn't a subscribable mailing list).

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[David Laight]

On Mon, 02 Nov 2026 07:34:37 -0700
Jonathan Corbet <corbet@lwn.net> wrote:

> "Rafael J. Wysocki (Intel)" <rafael@kernel.org> writes:
> 
> > So it occurred to me that it might be actually better to stop sending
> > messages directly to LKML subscribers and only make it available for
> > download somewhere and as a Lore archive.
> >
> > Is there really anyone depending on receiving all of the LKML traffic every day?  
> 
> * raises hand
> 
> Some of us crazy people really do depend on it, yes.

I certainly scan it.
It is also useful to have an archived local copy that can be searched.
I can see a point in not copying all of netdev to lkml, but there is
little point not copying patches to low-volume lists.

David

> 
> jon

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Jonathan Corbet]

David Laight <david.laight.linux@gmail.com> writes:

> On Mon, 02 Nov 2026 07:34:37 -0700
> Jonathan Corbet <corbet@lwn.net> wrote:
>
>> "Rafael J. Wysocki (Intel)" <rafael@kernel.org> writes:
>> 
>> > So it occurred to me that it might be actually better to stop sending
>> > messages directly to LKML subscribers and only make it available for
>> > download somewhere and as a Lore archive.
>> >
>> > Is there really anyone depending on receiving all of the LKML traffic every day?  
>> 
>> * raises hand
>> 
>> Some of us crazy people really do depend on it, yes.
>
> I certainly scan it.
> It is also useful to have an archived local copy that can be searched.

In truth...public-inbox is quite nice for the searching part of things;
I tend to use that rather than going into the email stream directly.

jon

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Joe Perches]

On Mon, 2026-11-02 at 08:47 -0700, Jonathan Corbet wrote:
> In truth...public-inbox is quite nice for the searching part of things;
> I tend to use that rather than going into the email stream directly.

I gave up on lkml after searching lore became reliable
several years ago.

What might be useful is something on lore/vger to be
able to match keyword searches similar to a finger like
registry and get forwarded threads that match.

Another possibility might be:

MAINTAINERS/get_maintainers is public and requires
senders generating the correct mailto: entries.

Maybe undo that and make lore/vger create all the
to/cc entries using a single kernel mailing address.

And if the received email by lore/vger already
has the suggested entries, don't duplicate it.

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Konstantin Ryabitsev]

On Mon, Nov 02, 2026 at 08:10:57AM -0800, Joe Perches wrote:
> MAINTAINERS/get_maintainers is public and requires
> senders generating the correct mailto: entries.
> 
> Maybe undo that and make lore/vger create all the
> to/cc entries using a single kernel mailing address.

The trouble I have with this approach is if we're down, nobody would get any
patches. The messy approach of sticking everyone into to/cc has built-in
resilience that continues to function even if someone knocked kernel.org off
the map.

-K

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Konstantin Ryabitsev]

On Mon, Nov 02, 2026 at 08:47:40AM -0700, Jonathan Corbet wrote:
> > I certainly scan it.
> > It is also useful to have an archived local copy that can be searched.
> 
> In truth...public-inbox is quite nice for the searching part of things;
> I tend to use that rather than going into the email stream directly.

Also, we now provide and maintain kgl, which lets you merge both worlds -- you
can both search AND push things into your inbox.

https://korgalore.docs.kernel.org/en/latest/

-K

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Geert Uytterhoeven]

On Mon, 2 Nov 2026 at 16:49, David Laight <david.laight.linux@gmail.com> wrote:
> On Mon, 02 Nov 2026 07:34:37 -0700
> Jonathan Corbet <corbet@lwn.net> wrote:
> > "Rafael J. Wysocki (Intel)" <rafael@kernel.org> writes:
> > > So it occurred to me that it might be actually better to stop sending
> > > messages directly to LKML subscribers and only make it available for
> > > download somewhere and as a Lore archive.
> > >
> > > Is there really anyone depending on receiving all of the LKML traffic every day?
> >
> > * raises hand
> >
> > Some of us crazy people really do depend on it, yes.
>
> I certainly scan it.
> It is also useful to have an archived local copy that can be searched.

Indeed. Sorry to say that, but Gmail web interface search is still
much more effective than lore web interface search.

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 0/2] get_maintainer: stop sending every patch to LKML

[David Laight]

On Mon, 2 Nov 2026 17:24:51 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> On Mon, 2 Nov 2026 at 16:49, David Laight <david.laight.linux@gmail.com> wrote:
> > On Mon, 02 Nov 2026 07:34:37 -0700
> > Jonathan Corbet <corbet@lwn.net> wrote:  
> > > "Rafael J. Wysocki (Intel)" <rafael@kernel.org> writes:  
> > > > So it occurred to me that it might be actually better to stop sending
> > > > messages directly to LKML subscribers and only make it available for
> > > > download somewhere and as a Lore archive.
> > > >
> > > > Is there really anyone depending on receiving all of the LKML traffic every day?  
> > >
> > > * raises hand
> > >
> > > Some of us crazy people really do depend on it, yes.  
> >
> > I certainly scan it.
> > It is also useful to have an archived local copy that can be searched.  
> 
> Indeed. Sorry to say that, but Gmail web interface search is still
> much more effective than lore web interface search.

You can't possibly look at lkml on any kind of web mail.
Although I have setup an smtp server in the last (20 years ago) I'm back
to the older scheme of doing hourly fetchmail pull from elsewhere.
(and lkml isn't fetched from this gmail address...)
I'm currently using claws as an mua, works moderately well apart from a small
memory leak and its insistence on putting each email in its own file.
But I can (and have) searched for things 'I know are there somewhere' using grep.

David

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

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Konstantin Ryabitsev]

On Mon, Nov 02, 2026 at 05:24:51PM +0100, Geert Uytterhoeven wrote:
> > I certainly scan it.
> > It is also useful to have an archived local copy that can be searched.
> 
> Indeed. Sorry to say that, but Gmail web interface search is still
> much more effective than lore web interface search.

Folks, I don't want this to turn into another thread of "me too" responses.

Yes, I know that some people still use it for a number of legitimate reasons
-- but these are few-and-far-between exceptions. I need this change because
the current status quo is NOT TENABLE. *Everyone's* quality of life is
affected because Gmail's throttling results in (looks) ~350,000 mails in the
queue, most of them waiting for Google to graciously allow us to talk to them.

So, we either unsubscribe all gmail addresses from LKML and prevent them from
resubscribing, or we do something less drastic and revert it to how it was
supposed to work in the first place -- only patches without a dedicated list
end up on LKML.

-K

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Rafael J. Wysocki (Intel)]

On Mon, Nov 2, 2026 at 6:56 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> On Mon, Nov 02, 2026 at 05:24:51PM +0100, Geert Uytterhoeven wrote:
> > > I certainly scan it.
> > > It is also useful to have an archived local copy that can be searched.
> >
> > Indeed. Sorry to say that, but Gmail web interface search is still
> > much more effective than lore web interface search.
>
> Folks, I don't want this to turn into another thread of "me too" responses.
>
> Yes, I know that some people still use it for a number of legitimate reasons
> -- but these are few-and-far-between exceptions. I need this change because
> the current status quo is NOT TENABLE. *Everyone's* quality of life is
> affected because Gmail's throttling results in (looks) ~350,000 mails in the
> queue, most of them waiting for Google to graciously allow us to talk to them.

So honestly, I'd do the drastic thing described below if I were you.

> So, we either unsubscribe all gmail addresses from LKML and prevent them from
> resubscribing, or we do something less drastic and revert it to how it was
> supposed to work in the first place -- only patches without a dedicated list
> end up on LKML.

Because this one depends on people stopping to send stuff to the LMKL
and that's about changing everyone's habits.  I'm not sure how
realistic it is TBH.

Rafael