Validating MAINTAINERS entries?

Validating MAINTAINERS entries?

[Stephen Hemminger]

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.

Re: Validating MAINTAINERS entries?

[Greg KH]

On Tue, Aug 09, 2022 at 05:13:16PM -0700, Stephen Hemminger 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.
> 
> 

Yes, it would be great to sweep the MAINTAINERS file once a year or so.
I know others have attempted to do it, but no one has really stuck with
it.  There's no real reason why anyone can't do this if they want to
send the patches for it.

thanks,

greg k-h

Re: Validating MAINTAINERS entries?

[Dan Carpenter]

On Tue, Aug 09, 2022 at 05:13:16PM -0700, Stephen Hemminger 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.
> 

Also we could add a RETIRED file or something for when people retire and
don't want get_maintainer.pl hassling them.

regards,
dan carpenter

Re: Validating MAINTAINERS entries?

[Greg KH]

On Wed, Aug 10, 2022 at 11:26:40AM +0300, Dan Carpenter wrote:
> On Tue, Aug 09, 2022 at 05:13:16PM -0700, Stephen Hemminger 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.
> > 
> 
> Also we could add a RETIRED file or something for when people retire and
> don't want get_maintainer.pl hassling them.

Isn't that what CREDITS is for?

Re: Validating MAINTAINERS entries?

[Lukas Bulwahn]

On Wed, Aug 10, 2022 at 10:50 AM Greg KH <greg@kroah.com> wrote:
>
> On Wed, Aug 10, 2022 at 11:26:40AM +0300, Dan Carpenter wrote:
> > On Tue, Aug 09, 2022 at 05:13:16PM -0700, Stephen Hemminger 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.
> > >
> >
> > Also we could add a RETIRED file or something for when people retire and
> > don't want get_maintainer.pl hassling them.
>
> Isn't that what CREDITS is for?
>

I agree with Greg here.

For:
"a RETIRED file or something for when people retire" -> CREDITS
"don't want get_maintainer.pl hassling them" -> .get_maintainer.ignore

Choose what fits for your case.

Lukas

Re: Validating MAINTAINERS entries?

[Dan Carpenter]

On Wed, Aug 10, 2022 at 10:55:44AM +0200, Lukas Bulwahn wrote:
> On Wed, Aug 10, 2022 at 10:50 AM Greg KH <greg@kroah.com> wrote:
> >
> > On Wed, Aug 10, 2022 at 11:26:40AM +0300, Dan Carpenter wrote:
> > > On Tue, Aug 09, 2022 at 05:13:16PM -0700, Stephen Hemminger 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.
> > > >
> > >
> > > Also we could add a RETIRED file or something for when people retire and
> > > don't want get_maintainer.pl hassling them.
> >
> > Isn't that what CREDITS is for?
> >
> 
> I agree with Greg here.
> 
> For:
> "a RETIRED file or something for when people retire" -> CREDITS
> "don't want get_maintainer.pl hassling them" -> .get_maintainer.ignore
> 
> Choose what fits for your case.

Perfect!  Thanks.  I had no idea about .get_maintainer.ignore and
started to implement it myself, but it turns out I am lazy and suck at
Perl.

regards,
dan carpenter

Re: Validating MAINTAINERS entries?

[Lee Jones]

On Wed, 10 Aug 2022, Lukas Bulwahn wrote:

> On Wed, Aug 10, 2022 at 10:50 AM Greg KH <greg@kroah.com> wrote:
> >
> > On Wed, Aug 10, 2022 at 11:26:40AM +0300, Dan Carpenter wrote:
> > > On Tue, Aug 09, 2022 at 05:13:16PM -0700, Stephen Hemminger 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.
> > > >
> > >
> > > Also we could add a RETIRED file or something for when people retire and
> > > don't want get_maintainer.pl hassling them.
> >
> > Isn't that what CREDITS is for?
> >
> 
> I agree with Greg here.
> 
> For:
> "a RETIRED file or something for when people retire" -> CREDITS

> "don't want get_maintainer.pl hassling them" -> .get_maintainer.ignore

This potentially looks good.  Does it ignore completely though?

Is there anything I can use that says:

  "Don't suggest mailing me for any files I'm not the maintainer of?"

I am presently plagued with reviews for lots of files that I've
touched over the years.  Even if the changes were trivial.

Or is this just an education point?

Re: Validating MAINTAINERS entries?

[Dan Carpenter]

On Wed, Aug 10, 2022 at 12:50:50PM +0100, Lee Jones wrote:
>
> I am presently plagued with reviews for lots of files that I've
> touched over the years.  Even if the changes were trivial.
> 
> Or is this just an education point?

Education is not the answer.

We've got thousands of devs and no one can keep track of everyone and
their motives.

When I send patches, there are few people that I know what they're about
and I manually delete them.  I also know which mailing lists those
people read so normally they're going to get the email even if they're
not on the CC list.

Other times, I wonder why maintainers are still on the CC list if they
haven't been active in years.  But I'm not going to manually remove
them.  It's worse to get chewed out for not CCing someone than for
including them.

The one split which is quite confusing to me is the netdev vs wireless
split.  For wireless patches, I generelly delete all the netdev
maintainers.  Some people I'm not sure what they care about so I leave
them.

regards,
dan carpenter

Re: Validating MAINTAINERS entries?

[Serge E. Hallyn]

On Wed, Aug 10, 2022 at 03:04:50PM +0300, Dan Carpenter wrote:
> On Wed, Aug 10, 2022 at 12:50:50PM +0100, Lee Jones wrote:
> >
> > I am presently plagued with reviews for lots of files that I've
> > touched over the years.  Even if the changes were trivial.
> > 
> > Or is this just an education point?
> 
> Education is not the answer.
> 
> We've got thousands of devs and no one can keep track of everyone and
> their motives.
> 
> When I send patches, there are few people that I know what they're about
> and I manually delete them.  I also know which mailing lists those
> people read so normally they're going to get the email even if they're
> not on the CC list.
> 
> Other times, I wonder why maintainers are still on the CC list if they
> haven't been active in years.  But I'm not going to manually remove
> them.  It's worse to get chewed out for not CCing someone than for
> including them.

Huh.  Chewed out for including them?  I had always thought that was *the*
point of MAINTAINERS.

Now, with lei (<3), MAINTAINERS becomes less important, as I can search
for the files/functions I'm interested in, and until someone starts
sending spam including patch hunks just to get pulled into such searches
that's more reliable than my shoddy spam filtering attempts on personal
email :)  The latter dropping important emails and letting through spam...

> The one split which is quite confusing to me is the netdev vs wireless
> split.  For wireless patches, I generelly delete all the netdev
> maintainers.  Some people I'm not sure what they care about so I leave
> them.
> 
> regards,
> dan carpenter

Re: Validating MAINTAINERS entries?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Wed, Aug 10, 2022 at 03:04:50PM +0300, Dan Carpenter wrote:
> On Wed, Aug 10, 2022 at 12:50:50PM +0100, Lee Jones wrote:

> > I am presently plagued with reviews for lots of files that I've
> > touched over the years.  Even if the changes were trivial.

> > Or is this just an education point?

> Education is not the answer.

> We've got thousands of devs and no one can keep track of everyone and
> their motives.

I think the issue there is more that if someone sent a drive by patch to
some driver they'll start showing up in the git history and often get
CCed on future changes going forwards, which can then result in getting
copied into further postings done by copying from prior postings.  That
does feel somewhat tractable to education, at least in the early stages.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Validating MAINTAINERS entries?

[Lee Jones]

On Wed, 10 Aug 2022, Mark Brown wrote:

> On Wed, Aug 10, 2022 at 03:04:50PM +0300, Dan Carpenter wrote:
> > On Wed, Aug 10, 2022 at 12:50:50PM +0100, Lee Jones wrote:
> 
> > > I am presently plagued with reviews for lots of files that I've
> > > touched over the years.  Even if the changes were trivial.
> 
> > > Or is this just an education point?
> 
> > Education is not the answer.
> 
> > We've got thousands of devs and no one can keep track of everyone and
> > their motives.
> 
> I think the issue there is more that if someone sent a drive by patch to
> some driver they'll start showing up in the git history and often get
> CCed on future changes going forwards, which can then result in getting
> copied into further postings done by copying from prior postings.  That
> does feel somewhat tractable to education, at least in the early stages.

How about default tooling values, get_maintainer.pl in this case?

I tend to over-ride this default to 75% to avoid the aforementioned:

  --git-min-percent => minimum percentage of commits required (default: 5)

5 is not a lot of percent for seldomly touched source files.

-- 
Lee Jones [李琼斯]

Re: Validating MAINTAINERS entries?

[Rob Herring]

On Wed, Aug 10, 2022 at 7:25 AM Lee Jones <lee@kernel.org> wrote:
>
> On Wed, 10 Aug 2022, Mark Brown wrote:
>
> > On Wed, Aug 10, 2022 at 03:04:50PM +0300, Dan Carpenter wrote:
> > > On Wed, Aug 10, 2022 at 12:50:50PM +0100, Lee Jones wrote:
> >
> > > > I am presently plagued with reviews for lots of files that I've
> > > > touched over the years.  Even if the changes were trivial.

After your W=1 and kerneldoc fixes, you're screwed. ;)

> >
> > > > Or is this just an education point?
> >
> > > Education is not the answer.

Yes. I'm convinced there is no way to solve these problems on the
sender side. I see plenty of cases of not running get_maintainers.pl.
You've got to filter out what you want on your end. And lei is great
for that.

> > > We've got thousands of devs and no one can keep track of everyone and
> > > their motives.
> >
> > I think the issue there is more that if someone sent a drive by patch to
> > some driver they'll start showing up in the git history and often get
> > CCed on future changes going forwards, which can then result in getting
> > copied into further postings done by copying from prior postings.  That
> > does feel somewhat tractable to education, at least in the early stages.
>
> How about default tooling values, get_maintainer.pl in this case?
>
> I tend to over-ride this default to 75% to avoid the aforementioned:
>
>   --git-min-percent => minimum percentage of commits required (default: 5)
>
> 5 is not a lot of percent for seldomly touched source files.

Send a patch. I would also bump --git-min-signatures from 1.

Rob

Re: Validating MAINTAINERS entries?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

On Wed, Aug 10, 2022 at 07:54:59AM -0600, Rob Herring wrote:
> On Wed, Aug 10, 2022 at 7:25 AM Lee Jones <lee@kernel.org> wrote:
> > On Wed, 10 Aug 2022, Mark Brown wrote:

> > > > Education is not the answer.

> Yes. I'm convinced there is no way to solve these problems on the
> sender side. I see plenty of cases of not running get_maintainers.pl.

We can't solve problems, but we can make things a bit better.

> You've got to filter out what you want on your end. And lei is great
> for that.

lei is too new for Debian stable :/

> >   --git-min-percent => minimum percentage of commits required (default: 5)

> > 5 is not a lot of percent for seldomly touched source files.

> Send a patch. I would also bump --git-min-signatures from 1.

Will that do the right thing in cases like recently added files?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Validating MAINTAINERS entries?

[Konstantin Ryabitsev]

On Wed, Aug 10, 2022 at 03:01:17PM +0100, Mark Brown wrote:
> > You've got to filter out what you want on your end. And lei is great
> > for that.
> 
> lei is too new for Debian stable :/

We also have plans to have centrally-managed lei filtering, available via
read-only mailboxes. This way "trawl all lists for relevant messages" can
happen on the kernel.org end and maintainers can make use of pre-filtered
data.

-K

Re: Validating MAINTAINERS entries?

[Rob Herring]

On Wed, Aug 10, 2022 at 8:01 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Aug 10, 2022 at 07:54:59AM -0600, Rob Herring wrote:
> > On Wed, Aug 10, 2022 at 7:25 AM Lee Jones <lee@kernel.org> wrote:
> > > On Wed, 10 Aug 2022, Mark Brown wrote:
>
> > > > > Education is not the answer.
>
> > Yes. I'm convinced there is no way to solve these problems on the
> > sender side. I see plenty of cases of not running get_maintainers.pl.
>
> We can't solve problems, but we can make things a bit better.
>
> > You've got to filter out what you want on your end. And lei is great
> > for that.
>
> lei is too new for Debian stable :/

Meaning it's not packaged or needs newer dependencies?

> > >   --git-min-percent => minimum percentage of commits required (default: 5)
>
> > > 5 is not a lot of percent for seldomly touched source files.
>
> > Send a patch. I would also bump --git-min-signatures from 1.
>
> Will that do the right thing in cases like recently added files?

Yes, because I'm sure checkpatch.pl was run on the patch adding the
files and it tells you 'added file, need a MAINTAINERS entry?'.

Really, I would (and do) turn off gitfallback completely by default.
If someone wants to be CCed and there's not a MAINTAINERS entry, then
that's on them.

Rob

Re: Validating MAINTAINERS entries?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

On Wed, Aug 10, 2022 at 08:20:32AM -0600, Rob Herring wrote:
> On Wed, Aug 10, 2022 at 8:01 AM Mark Brown <broonie@kernel.org> wrote:
> > On Wed, Aug 10, 2022 at 07:54:59AM -0600, Rob Herring wrote:

> > > You've got to filter out what you want on your end. And lei is great
> > > for that.

> > lei is too new for Debian stable :/

> Meaning it's not packaged or needs newer dependencies?

IIRC it (well, public-inbox) is packaged but is an old version without
the lei functionality, and/or there were some dependency issues.  It was
a while ago that I looked.

> > Will that do the right thing in cases like recently added files?

> Yes, because I'm sure checkpatch.pl was run on the patch adding the
> files and it tells you 'added file, need a MAINTAINERS entry?'.

Right, if people run and pay attention to checkpatch.

> Really, I would (and do) turn off gitfallback completely by default.
> If someone wants to be CCed and there's not a MAINTAINERS entry, then
> that's on them.

Yes.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Validating MAINTAINERS entries?

[Sudip Mukherjee]

On Wed, Aug 10, 2022 at 3:36 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Aug 10, 2022 at 08:20:32AM -0600, Rob Herring wrote:
> > On Wed, Aug 10, 2022 at 8:01 AM Mark Brown <broonie@kernel.org> wrote:
> > > On Wed, Aug 10, 2022 at 07:54:59AM -0600, Rob Herring wrote:
>
> > > > You've got to filter out what you want on your end. And lei is great
> > > > for that.
>
> > > lei is too new for Debian stable :/
>
> > Meaning it's not packaged or needs newer dependencies?
>
> IIRC it (well, public-inbox) is packaged but is an old version without
> the lei functionality, and/or there were some dependency issues.  It was
> a while ago that I looked.

v1.8.0 which is the latest, is in Debian and also in bullseye-backports.

-- 
Regards
Sudip

Re: Validating MAINTAINERS entries?

[Lee Jones]

On Wed, 10 Aug 2022, Rob Herring wrote:

> On Wed, Aug 10, 2022 at 7:25 AM Lee Jones <lee@kernel.org> wrote:
> >
> > On Wed, 10 Aug 2022, Mark Brown wrote:
> >
> > > On Wed, Aug 10, 2022 at 03:04:50PM +0300, Dan Carpenter wrote:
> > > > On Wed, Aug 10, 2022 at 12:50:50PM +0100, Lee Jones wrote:
> > >
> > > > > I am presently plagued with reviews for lots of files that I've
> > > > > touched over the years.  Even if the changes were trivial.
> 
> After your W=1 and kerneldoc fixes, you're screwed. ;)

Yes, and the tragic thing is, I still have aspirations to go finish that!

> > > > > Or is this just an education point?
> > >
> > > > Education is not the answer.
> 
> Yes. I'm convinced there is no way to solve these problems on the
> sender side. I see plenty of cases of not running get_maintainers.pl.
> You've got to filter out what you want on your end. And lei is great
> for that.
> 
> > > > We've got thousands of devs and no one can keep track of everyone and
> > > > their motives.
> > >
> > > I think the issue there is more that if someone sent a drive by patch to
> > > some driver they'll start showing up in the git history and often get
> > > CCed on future changes going forwards, which can then result in getting
> > > copied into further postings done by copying from prior postings.  That
> > > does feel somewhat tractable to education, at least in the early stages.
> >
> > How about default tooling values, get_maintainer.pl in this case?
> >
> > I tend to over-ride this default to 75% to avoid the aforementioned:
> >
> >   --git-min-percent => minimum percentage of commits required (default: 5)
> >
> > 5 is not a lot of percent for seldomly touched source files.
> 
> Send a patch. I would also bump --git-min-signatures from 1.

I can do that.  Fair warning, it won't be until around mid-cycle.

-- 
Lee Jones [李琼斯]

Re: Validating MAINTAINERS entries?

[Geert Uytterhoeven]

On Wed, Aug 10, 2022 at 2:50 PM Mark Brown <broonie@kernel.org> wrote:
> On Wed, Aug 10, 2022 at 03:04:50PM +0300, Dan Carpenter wrote:
> > On Wed, Aug 10, 2022 at 12:50:50PM +0100, Lee Jones wrote:
> > > I am presently plagued with reviews for lots of files that I've
> > > touched over the years.  Even if the changes were trivial.
>
> > > Or is this just an education point?
>
> > Education is not the answer.
>
> > We've got thousands of devs and no one can keep track of everyone and
> > their motives.
>
> I think the issue there is more that if someone sent a drive by patch to
> some driver they'll start showing up in the git history and often get
> CCed on future changes going forwards, which can then result in getting
> copied into further postings done by copying from prior postings.  That
> does feel somewhat tractable to education, at least in the early stages.

And for drive-by changes to Kconfig files or Makefiles, it is amplified
to any other sections in these files :-(

Perhaps scripts/get_maintainer.pl can be taught to only consider the
subsystem maintainer, and ignore git history, for changes to Makefiles
and Kconfig files?

Or move the Kconfig/Makefile bits into the driver sources, next to
the MODULE_*() bits, which I believe was part of Roman Zippel's big
plan when he wrote the new Kconfig system...

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: Validating MAINTAINERS entries?

[Christoph Hellwig]

On Thu, Aug 11, 2022 at 10:35:52AM +0200, Geert Uytterhoeven wrote:
> Perhaps scripts/get_maintainer.pl can be taught to only consider the
> subsystem maintainer, and ignore git history, for changes to Makefiles
> and Kconfig files?

In general looking at git history is pretty much always the wrong thing,
except maybe for the initial commit.

> Or move the Kconfig/Makefile bits into the driver sources, next to
> the MODULE_*() bits, which I believe was part of Roman Zippel's big
> plan when he wrote the new Kconfig system...

I don't think having Kconfig in source files is a good thing.  Being
able to integrate the Makefile into Kconfig OTOH would be really nice..

config FOOBAR
	tristate 'Foo driver'
	depends on PCI
	help
	   This is the driver for the foo hardware.
	module foo
	sources foo_core.c foo_sysfs.c foo_debugfs.c

Re: Validating MAINTAINERS entries?

[Lukas Bulwahn]

On Wed, Aug 10, 2022 at 10:27 AM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> On Tue, Aug 09, 2022 at 05:13:16PM -0700, Stephen Hemminger 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.
> >
>
> Also we could add a RETIRED file or something for when people retire and
> don't want get_maintainer.pl hassling them.
>

Dan, I believe this exists already: .get_maintainer.ignore

For many years, there was only one developer using this feature, now
we have at least two developers. It seems that many others resolve
this issue just in their local setup differently, though.

Lukas

Re: Validating MAINTAINERS entries?

[Lukas Bulwahn]

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