From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
To: stephen@networkplumber.org
Cc: ksummit@lists.linux.dev
Subject: Re: Validating MAINTAINERS entries?
Date: Wed, 10 Aug 2022 10:42:28 +0200 [thread overview]
Message-ID: <CAKXUXMwRYy8pqLTzfFoxhfS5UvDZEgZ6WxQ_YQcjzdRGmTX3qQ@mail.gmail.com> (raw)
In-Reply-To: <20220809171316.1d6ce319@hermes.local>
On Wed, Aug 10, 2022 at 2:13 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> Several times in the past, when using MAINTAINERS list either automatically
> (or from manual entry) have found the mailing address in the file is no longer valid.
>
> What about doing an annual probe mail to all maintainers and sending
> a patch to prune out any addresses that auto respond as dead.
> This won't catch ghost entries but would find any dead ones.
>
In many cases, you can avoid the noise of sending out a probe mail,
but simply checking the lore.kernel.org archives for an email response
from that email within the last year.
Many maintainers are simply going to be active, so that.
Then, you may consider just the remaining cases:
Some maintainers use a different email for responding than for
receiving patches. The email address for receiving patches is in
MAINTAINERS, the email address for responding is visible on
lore.kernel.org.
Some maintainers do not even need to respond within the last year, as
no patches were sent to the maintainer's area of responsibility.
Some emails are in fact dead.
Alternatively, you could just offer "a service" for kernel developers
to forward the automated emails from servers, when an email is dead,
to some other email, and then, you go through those and create the
needed patches to MAINTAINERS.
Anyway, creating this clean-up patch for MAINTAINERS is probably still
some semi-automated effort and not fully automatic (as e.g., you
probably want to split this patch going to different subsystem
maintainers and get their acknowledgement), though.
I am also aware of many other clean-up aspects in MAINTAINERS. Just
trying to keep ./scripts/get_maintainer.pl --self-test=patterns
without warnings is already a task that can keep you busy, which I now
know from trying to do so for two or three years.
Lukas
prev parent reply other threads:[~2022-08-10 8:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-10 0:13 Stephen Hemminger
2022-08-10 8:23 ` Greg KH
2022-08-10 8:26 ` Dan Carpenter
2022-08-10 8:36 ` Greg KH
2022-08-10 8:55 ` Lukas Bulwahn
2022-08-10 9:10 ` Dan Carpenter
2022-08-10 11:50 ` Lee Jones
2022-08-10 12:04 ` Dan Carpenter
2022-08-10 12:12 ` Serge E. Hallyn
2022-08-10 12:50 ` Mark Brown
2022-08-10 13:25 ` Lee Jones
2022-08-10 13:54 ` Rob Herring
2022-08-10 14:01 ` Mark Brown
2022-08-10 14:19 ` Konstantin Ryabitsev
2022-08-10 14:20 ` Rob Herring
2022-08-10 14:35 ` Mark Brown
2022-08-11 12:36 ` Sudip Mukherjee
2022-08-10 15:29 ` Lee Jones
2022-08-11 8:35 ` Geert Uytterhoeven
2022-08-11 8:42 ` Christoph Hellwig
2022-08-10 8:46 ` Lukas Bulwahn
2022-08-10 8:42 ` Lukas Bulwahn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKXUXMwRYy8pqLTzfFoxhfS5UvDZEgZ6WxQ_YQcjzdRGmTX3qQ@mail.gmail.com \
--to=lukas.bulwahn@gmail.com \
--cc=ksummit@lists.linux.dev \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox