The documentation implies that patches should be primarily sent to a
subsystem-specific mailing list [0]. Make get_maintainer only return the
generic [email protected] ("THE REST") list when no other
matching mailing list is found.
Most patches sent to lkml today are also sent to some other list. This
change should lower the message volume on lkml in the long run, making
the list more useful for those cases where it's the only option.
[0]: Documentation/process/submitting-patches.rst:
> You should also normally choose at least one mailing list to receive a
> copy of your patch set. [email protected] functions as a
> list of last resort, but the volume on that list has caused a number of
> developers to tune it out. Look in the MAINTAINERS file for a
> subsystem-specific list; your patch will probably get more attention
> there.
Signed-off-by: Hannu Hartikainen <[email protected]>
---
I'm not sure if this is technically the best solution so I'm looking
forward to review comments. But process-wise I think this should be a
good change. Looking at tutorials and such, many people seem to just
blindly run scripts/get_maintainer.pl and send their patches to all the
addresses the script outputs. This must inflate the list a lot, making
it difficult to follow and making it much more difficult to get readers
for patches belonging to the list (including this one, ironically).
scripts/get_maintainer.pl | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 2075db0c08b8..c0a8dd5dfdbf 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -627,6 +627,7 @@ my %email_hash_address;
my @email_to = ();
my %hash_list_to;
my @list_to = ();
+my @list_the_rest_to = ();
my @scm = ();
my @web = ();
my @subsystem = ();
@@ -951,6 +952,11 @@ sub get_maintainers {
}
}
+ # if no other list would be printed, fall back to THE REST
+ if (scalar(@list_to) == 0) {
+ @list_to = @list_the_rest_to
+ }
+
foreach my $email (@email_to, @list_to) {
$email->[0] = deduplicate_email($email->[0]);
}
@@ -1303,10 +1309,6 @@ sub get_list_role {
my $subsystem = get_subsystem_name($index);
- if ($subsystem eq "THE REST") {
- $subsystem = "";
- }
-
return $subsystem;
}
@@ -1355,8 +1357,13 @@ sub add_categories {
}
} else {
$hash_list_to{lc($list_address)} = 1;
- push(@list_to, [$list_address,
- "open list${list_role}"]);
+ if ($list_role eq ":THE REST") {
+ push(@list_the_rest_to, [$list_address,
+ "open list"]);
+ } else {
+ push(@list_to, [$list_address,
+ "open list${list_role}"]);
+ }
}
}
}
--
2.32.0
On Tue, 2021-07-06 at 11:33 +0300, Hannu Hartikainen wrote:
> The documentation implies that patches should be primarily sent to a
> subsystem-specific mailing list [0]. Make get_maintainer only return the
> generic [email protected] ("THE REST") list when no other
> matching mailing list is found.
>
> Most patches sent to lkml today are also sent to some other list. This
> change should lower the message volume on lkml in the long run, making
> the list more useful for those cases where it's the only option.
>
> [0]: Documentation/process/submitting-patches.rst:
> > You should also normally choose at least one mailing list to receive a
> > copy of your patch set. [email protected] functions as a
> > list of last resort, but the volume on that list has caused a number of
> > developers to tune it out. Look in the MAINTAINERS file for a
> > subsystem-specific list; your patch will probably get more attention
> > there.
>
> Signed-off-by: Hannu Hartikainen <[email protected]>
> ---
>
> I'm not sure if this is technically the best solution so I'm looking
> forward to review comments. But process-wise I think this should be a
> good change.
Almost no one reads lkml directly anyway and I rather like that lkml
gets all copies.
This allows lore.kernel.org/lkml to have a relatively complete searchable
database of all kernel related patch submissions.
Another solution might be an searchable aggregation mechanism at lore,
but I believe one currently does not exist.
That _might_ allow a similar search mechanism.
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
The proposed patch seems overly complicated.
Hi, and thanks for the review!
On Tue, 06 Jul 2021 09:00:42 -0700, Joe Perches <[email protected]> wrote:
> Almost no one reads lkml directly anyway and I rather like that lkml
> gets all copies.
>
> This allows lore.kernel.org/lkml to have a relatively complete searchable
> database of all kernel related patch submissions.
I hadn't considered that and the documentation gave me the wrong idea.
I'll submit a patch that clarifies the documentation instead. Thanks!
Hannu