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

["Jürgen Groß" <jgross@suse.com>]

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