| Message ID | 20210920080635.253826-1-u.kleine-koenig@pengutronix.de (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | MAINTAINERS: Remove Matt Mackall as his identity is obsolete | expand |
Hi Uwe, On Mon, Sep 20, 2021 at 11:52 AM Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > The mails I sent to Matt on September 14 and 20 both were refused by the > MTA responsible for selenic.com (i.e. waste.org) with: > > 554 5.7.1 <mpm@selenic.com>: Recipient address rejected: This identity is obsolete > > Also the most recent commit that involved him (ignoring "Cc: Matt > Mackall <mpm@selenic.com>" footers) is commit 330e0a01d54c (MAINTAINERS: > Theodore Ts'o is taking over the random driver) where he was removed > from the entry for random number drivers in 2012. > > So drop him completely from the list of maintainers. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > --- > MAINTAINERS | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index d7b4f32875a9..805630c67a1f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6812,7 +6812,6 @@ F: drivers/media/usb/em28xx/ > > EMBEDDED LINUX > M: Paul Gortmaker <paul.gortmaker@windriver.com> > -M: Matt Mackall <mpm@selenic.com> Perhaps this should be replaced by "Olivia Mackall <olivia@selenic.com>" instead? > M: David Woodhouse <dwmw2@infradead.org> > L: linux-embedded@vger.kernel.org > S: Maintained > @@ -8157,7 +8156,6 @@ F: include/trace/events/hwmon*.h > K: (devm_)?hwmon_device_(un)?register(|_with_groups|_with_info) > > HARDWARE RANDOM NUMBER GENERATOR CORE > -M: Matt Mackall <mpm@selenic.com> > M: Herbert Xu <herbert@gondor.apana.org.au> > L: linux-crypto@vger.kernel.org > S: Odd fixes Gr{oetje,eeting}s, Geert
Hello, On Mon, Sep 20, 2021 at 03:01:25PM +0200, Geert Uytterhoeven wrote: > On Mon, Sep 20, 2021 at 11:52 AM Uwe Kleine-König > <u.kleine-koenig@pengutronix.de> wrote: > > The mails I sent to Matt on September 14 and 20 both were refused by the > > MTA responsible for selenic.com (i.e. waste.org) with: > > > > 554 5.7.1 <mpm@selenic.com>: Recipient address rejected: This identity is obsolete > > > > Also the most recent commit that involved him (ignoring "Cc: Matt > > Mackall <mpm@selenic.com>" footers) is commit 330e0a01d54c (MAINTAINERS: > > Theodore Ts'o is taking over the random driver) where he was removed > > from the entry for random number drivers in 2012. > > > > So drop him completely from the list of maintainers. > > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > --- > > MAINTAINERS | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index d7b4f32875a9..805630c67a1f 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -6812,7 +6812,6 @@ F: drivers/media/usb/em28xx/ > > > > EMBEDDED LINUX > > M: Paul Gortmaker <paul.gortmaker@windriver.com> > > -M: Matt Mackall <mpm@selenic.com> > > Perhaps this should be replaced by > "Olivia Mackall <olivia@selenic.com>" instead? I think we need some feedback from Olivia here? At least I don't know more than I wrote in the commit log and so I'm not in a position to decide anything here. Best regards Uwe
Hi Tim, On Mon, Oct 18, 2021 at 03:17:22PM -0600, Tim Bird wrote: > On Mon, Sep 20, 2021 at 3:52 AM Uwe Kleine-König wrote: > > > > The mails I sent to Matt on September 14 and 20 both were refused by the > > MTA responsible for selenic.com (i.e. waste.org) with: > > > > 554 5.7.1 <mpm@selenic.com>: Recipient address rejected: This identity is obsolete > > > > Also the most recent commit that involved him (ignoring "Cc: Matt > > Mackall <mpm@selenic.com>" footers) is commit 330e0a01d54c (MAINTAINERS: > > Theodore Ts'o is taking over the random driver) where he was removed > > from the entry for random number drivers in 2012. > > > > So drop him completely from the list of maintainers. > > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > --- > > MAINTAINERS | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index d7b4f32875a9..805630c67a1f 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -6812,7 +6812,6 @@ F: drivers/media/usb/em28xx/ > > > > EMBEDDED LINUX > > M: Paul Gortmaker <paul.gortmaker@windriver.com> > > -M: Matt Mackall <mpm@selenic.com> > > M: David Woodhouse <dwmw2@infradead.org> > > L: linux-embedded@vger.kernel.org > > S: Maintained > > @@ -8157,7 +8156,6 @@ F: include/trace/events/hwmon*.h > > K: (devm_)?hwmon_device_(un)?register(|_with_groups|_with_info) > > > I think an overhaul of the "EMBEDDED LINUX" MAINTAINERS entry > is long-overdue. > > No offense to any of the 3 persons listed, but I think the kernel developer > community would be better served by a group of individuals with a more > current active role in embedded linux. I have a few names I'll toss out for > candidates: Matt Porter, Kevin Hilman, Thomas Gleixner, Thomas > Petazonni, Laurent Pinchart, and Uwe Kleine-König (and maybe even > myself). > > This entry in the MAINTAINERS file is somewhat special, in that it > covers a "field of endeavor" rather than a specific set of files or > directories. > > Thoughts? Thank you for volunteering me :-) I was indeed wondering about this particular MAINTAINERS entry. As it doesn't cover any particular set of files, directories, drivers, subsystems or architectures, what does being listed here endeavour ? > ... Volunteers? > > > HARDWARE RANDOM NUMBER GENERATOR CORE > > -M: Matt Mackall <mpm@selenic.com> > > M: Herbert Xu <herbert@gondor.apana.org.au> > > L: linux-crypto@vger.kernel.org > > S: Odd fixes
On Tue, 2021-10-19 at 09:55 +0300, Laurent Pinchart wrote: > Hi Tim, > > On Mon, Oct 18, 2021 at 03:17:22PM -0600, Tim Bird wrote: > > I think an overhaul of the "EMBEDDED LINUX" MAINTAINERS entry > > is long-overdue. > > > > No offense to any of the 3 persons listed, but I think the kernel developer > > community would be better served by a group of individuals with a more > > current active role in embedded linux. I have a few names I'll > > toss out for > > candidates: Matt Porter, Kevin Hilman, Thomas Gleixner, Thomas > > Petazonni, Laurent Pinchart, and Uwe Kleine-König (and maybe even > > myself). > > > > This entry in the MAINTAINERS file is somewhat special, in that it > > covers a "field of endeavor" rather than a specific set of files or > > directories. > > > > Thoughts? > > Thank you for volunteering me :-) > > I was indeed wondering about this particular MAINTAINERS entry. As it > doesn't cover any particular set of files, directories, drivers, > subsystems or architectures, what does being listed here endeavour ? Basically nothing; I was going to suggest removing it entirely. There's certainly no point listing me there any more. Once upon a time it involved a certain amount of heckling about memory usage and "your hash table doesn't need to be that large" but that ship sailed a long time ago :)
On Tue, Oct 19, 2021 at 10:33:10AM +0100, David Woodhouse wrote: > On Tue, 2021-10-19 at 09:55 +0300, Laurent Pinchart wrote: > > Hi Tim, > > > > On Mon, Oct 18, 2021 at 03:17:22PM -0600, Tim Bird wrote: > > > I think an overhaul of the "EMBEDDED LINUX" MAINTAINERS entry > > > is long-overdue. > > > > > > No offense to any of the 3 persons listed, but I think the kernel developer > > > community would be better served by a group of individuals with a more > > > current active role in embedded linux. I have a few names I'll > > > toss out for > > > candidates: Matt Porter, Kevin Hilman, Thomas Gleixner, Thomas > > > Petazonni, Laurent Pinchart, and Uwe Kleine-König (and maybe even > > > myself). > > > > > > This entry in the MAINTAINERS file is somewhat special, in that it > > > covers a "field of endeavor" rather than a specific set of files or > > > directories. > > > > > > Thoughts? > > > > Thank you for volunteering me :-) > > > > I was indeed wondering about this particular MAINTAINERS entry. As it > > doesn't cover any particular set of files, directories, drivers, > > subsystems or architectures, what does being listed here endeavour ? > > Basically nothing; I was going to suggest removing it entirely. There's > certainly no point listing me there any more. > > Once upon a time it involved a certain amount of heckling about memory > usage and "your hash table doesn't need to be that large" but that ship > sailed a long time ago :) Heckling is still an option without a MAINTAINERS entry I suppose :-) I wouldn't object if we were to remove it.
On Tue, Oct 19, 2021 at 11:48 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > On Tue, Oct 19, 2021 at 10:33:10AM +0100, David Woodhouse wrote: > > On Tue, 2021-10-19 at 09:55 +0300, Laurent Pinchart wrote: > > > On Mon, Oct 18, 2021 at 03:17:22PM -0600, Tim Bird wrote: > > > > I think an overhaul of the "EMBEDDED LINUX" MAINTAINERS entry > > > > is long-overdue. > > > > > > > > No offense to any of the 3 persons listed, but I think the kernel developer > > > > community would be better served by a group of individuals with a more > > > > current active role in embedded linux. I have a few names I'll > > > > toss out for > > > > candidates: Matt Porter, Kevin Hilman, Thomas Gleixner, Thomas > > > > Petazonni, Laurent Pinchart, and Uwe Kleine-König (and maybe even > > > > myself). > > > > > > > > This entry in the MAINTAINERS file is somewhat special, in that it > > > > covers a "field of endeavor" rather than a specific set of files or > > > > directories. > > > > > > > > Thoughts? > > > > > > Thank you for volunteering me :-) > > > > > > I was indeed wondering about this particular MAINTAINERS entry. As it > > > doesn't cover any particular set of files, directories, drivers, > > > subsystems or architectures, what does being listed here endeavour ? > > > > Basically nothing; I was going to suggest removing it entirely. There's > > certainly no point listing me there any more. > > > > Once upon a time it involved a certain amount of heckling about memory > > usage and "your hash table doesn't need to be that large" but that ship > > sailed a long time ago :) > > Heckling is still an option without a MAINTAINERS entry I suppose :-) Don't worry, I keep on sailing ;-) > I wouldn't object if we were to remove it. +1 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
Geert Uytterhoeven <geert@linux-m68k.org> writes: > On Tue, Oct 19, 2021 at 11:48 AM Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: >> On Tue, Oct 19, 2021 at 10:33:10AM +0100, David Woodhouse wrote: >> > On Tue, 2021-10-19 at 09:55 +0300, Laurent Pinchart wrote: >> > > On Mon, Oct 18, 2021 at 03:17:22PM -0600, Tim Bird wrote: >> > > > I think an overhaul of the "EMBEDDED LINUX" MAINTAINERS entry >> > > > is long-overdue. >> > > > >> > > > No offense to any of the 3 persons listed, but I think the kernel developer >> > > > community would be better served by a group of individuals with a more >> > > > current active role in embedded linux. I have a few names I'll >> > > > toss out for >> > > > candidates: Matt Porter, Kevin Hilman, Thomas Gleixner, Thomas >> > > > Petazonni, Laurent Pinchart, and Uwe Kleine-König (and maybe even >> > > > myself). >> > > > >> > > > This entry in the MAINTAINERS file is somewhat special, in that it >> > > > covers a "field of endeavor" rather than a specific set of files or >> > > > directories. >> > > > >> > > > Thoughts? >> > > >> > > Thank you for volunteering me :-) >> > > >> > > I was indeed wondering about this particular MAINTAINERS entry. As it >> > > doesn't cover any particular set of files, directories, drivers, >> > > subsystems or architectures, what does being listed here endeavour ? >> > >> > Basically nothing; I was going to suggest removing it entirely. There's >> > certainly no point listing me there any more. >> > >> > Once upon a time it involved a certain amount of heckling about memory >> > usage and "your hash table doesn't need to be that large" but that ship >> > sailed a long time ago :) >> >> Heckling is still an option without a MAINTAINERS entry I suppose :-) > > Don't worry, I keep on sailing ;-) > >> I wouldn't object if we were to remove it. > > +1 > Agreed. Let's just drop this entry. Kevin
> -----Original Message----- > From: Kevin Hilman <khilman@baylibre.com> > > Geert Uytterhoeven <geert@linux-m68k.org> writes: > > > On Tue, Oct 19, 2021 at 11:48 AM Laurent Pinchart > > <laurent.pinchart@ideasonboard.com> wrote: > >> On Tue, Oct 19, 2021 at 10:33:10AM +0100, David Woodhouse wrote: > >> > On Tue, 2021-10-19 at 09:55 +0300, Laurent Pinchart wrote: > >> > > On Mon, Oct 18, 2021 at 03:17:22PM -0600, Tim Bird wrote: > >> > > > I think an overhaul of the "EMBEDDED LINUX" MAINTAINERS entry > >> > > > is long-overdue. > >> > > > > >> > > > No offense to any of the 3 persons listed, but I think the kernel developer > >> > > > community would be better served by a group of individuals with a more > >> > > > current active role in embedded linux. I have a few names I'll > >> > > > toss out for > >> > > > candidates: Matt Porter, Kevin Hilman, Thomas Gleixner, Thomas > >> > > > Petazonni, Laurent Pinchart, and Uwe Kleine-König (and maybe even > >> > > > myself). > >> > > > > >> > > > This entry in the MAINTAINERS file is somewhat special, in that it > >> > > > covers a "field of endeavor" rather than a specific set of files or > >> > > > directories. > >> > > > > >> > > > Thoughts? > >> > > > >> > > Thank you for volunteering me :-) > >> > > > >> > > I was indeed wondering about this particular MAINTAINERS entry. As it > >> > > doesn't cover any particular set of files, directories, drivers, > >> > > subsystems or architectures, what does being listed here endeavour ? > >> > > >> > Basically nothing; I was going to suggest removing it entirely. There's > >> > certainly no point listing me there any more. > >> > > >> > Once upon a time it involved a certain amount of heckling about memory > >> > usage and "your hash table doesn't need to be that large" but that ship > >> > sailed a long time ago :) > >> > >> Heckling is still an option without a MAINTAINERS entry I suppose :-) > > > > Don't worry, I keep on sailing ;-) > > > >> I wouldn't object if we were to remove it. > > > > +1 > > > > Agreed. Let's just drop this entry. Well... Let me give some history, and then pontificate a little on the entry. Originally, this entry was created after Andrew Morton gave a talk at an early Embedded Linux Conference, saying that there should be some "ombudsman" for embedded issues in the kernel. This was in 2008. The linux-embedded mailing list was created about the same time. The thinking was that there are issues that transcend any particular sub-system, directory, or file, such as boot time or system size or real-time. Changes to keep these system-wide metrics in check might need the assistance of a respected upstream maintainer, who could guide developers working in these areas, or who could help keep other kernel maintainers apprised of requirements in these areas for embedded products. I would say that realtime has been shepherded pretty well by Thomas Gleixner (and it's almost all upstream!), independent of this entry. The other system-wide issues (boot time and system size), people have pretty much given up on, although there is the occasional patch to address a micro-symptom of the problem. But no one is riding herd over the entire kernel to make sure that it doesn't get too big, or boot too slow (or use too much power). This entry, and the linux-embedded mailing list itself, have not functioned as originally intended in years, and I doubt anyone uses this information. The tools don't use it (e.g. get_maintainers.pl is never going to use this entry to recommend someone be CC'ed on an "embedded" patch). So, I guess I'd vote to get rid of it as well. But, I'm a little sad to see it go... :-( I'll probably never see Linux on a cereal box. -- Tim
On 10/19/21 5:54 PM, Tim.Bird@sony.com wrote: > Well... Let me give some history, and then pontificate a little on the entry. > > Originally, this entry was created after Andrew Morton gave a talk at > an early Embedded Linux Conference, saying that there should be some > "ombudsman" for embedded issues in the kernel. This was in 2008. I've been doing this sort of thing on and off for a while, but I admit to gradually burning out over the years (sometime between https://www.spinics.net/lists/linux-embedded/msg00148.html and https://lkml.org/lkml/2017/9/13/651) as linux-kernel became actively hostile to hobbyists. > The linux-embedded mailing list was created about the same time. > The thinking was that there are issues that transcend any particular > sub-system, directory, or file, such as boot time or system size or > real-time. Changes to keep these system-wide metrics in check might > need the assistance of a respected upstream maintainer, who could > guide developers working in these areas, or who could help keep > other kernel maintainers apprised of requirements in these areas > for embedded products. Greg KH wouldn't listen to me when I was Documention maintainer. He wouldn't listen when I was busybox maintainer. Maintainer-without-portfolio ain't gonna get him to start. Keep in mind Greg and Kay Sievers were joined at the hip until Linus threw Kay out of Linux dev and he bogged off to systemd. If you point out things like "sysfs should to present a stable API to userspace" or "it's a bad idea to depend on magic packages like udev or systemd as things every Linux system must not only use verbatim from a single upstream supplier but must replace every time they upgrade the kernel", Greg is reliably against them. > I would say that realtime has been shepherded pretty well by Thomas > Gleixner (and it's almost all upstream!), independent of this entry. > The other system-wide issues (boot time and system size), people > have pretty much given up on, Nah, I've gotten them trimmed/working acceptably well in my systems. I just don't bother trying to poke linux-kernel about it anymore. Not since the Linux Foundation chased hobbyists out of Linux to the point where people literally started asking if hobbysts had ever really existed (circa https://lwn.net/Articles/563578/). Peter Anvin is actively hostile to the idea of reducing build-time dependencies (http://lkml.iu.edu/hypermail/linux/kernel/0802.1/4400.html) to the point that when my perl removal patches finally got traction in 2013 (after 5 years of follow-through), he switched one of his perl scripts to use bc instead so things like Gentoo and Linux From Scratch had to add a new build dependency for him (neither was installing bc before). This was after I'd convinced Denys to make ash do 64 bit math on 32 bit hosts so my shell translation ran under bash dash and ash, and then when that was rejected rewrote it in C, and when Andrew Morton went around him to take my patches THEN he piped up with a patch to keep the build complex. Circa 2018 or so when they made kconfig turing complete (so make oldconfig on a new kernel can "rm -rf ~" if it wants to) they added flex and bison as dependencies needed to run kconfig, when previously kconfig had .shipped versions of those files so as NOT to require that. I just bisected the v5.14 regression where building x86-64 breaks trying to #include "gelf.h" (from Jim Henson's Dark Crystal package), which I already personally fought off in 2018 for my own builds: https://twitter.com/landley/status/1064994639487426560 And the commit I just bisected it to (http://lkml.iu.edu/hypermail/linux/kernel/2110.3/00009.html) EXPLICITLY broke x86-64 (and only x86-64) to have a unique build-time dependency. In a patch that did NOTHING ELSE. Because why not? > although there is the occasional > patch to address a micro-symptom of the problem. But no one > is riding herd over the entire kernel to make sure that it doesn't > get too big, or boot too slow (or use too much power). Because the lkml clique is circling the wagons tighter and tighter until they achieve a black hole via proctology? There doesn't seem to be any actual malice, just a whole lot of territoriality and disdain for outsiders. It's not a thing that somebody's gonna do for fun, a topic you and I emailed about earlier this year if I recall. > This entry, and the linux-embedded mailing list itself, have not > functioned as originally intended in years, and I doubt anyone > uses this information. The tools don't use it > (e.g. get_maintainers.pl is never going to use this entry to > recommend someone be CC'ed on an "embedded" patch). Because that perl script matches files and the maintainers entry has no files. (Not that cc-ing random patches to lists strikes me as particularly useful. It usually just drives down the signal to noise ratio of the list in my experience. Patch 22/47 applies to arch/sh and thus the whole series is cc'd there...) > So, I guess I'd vote to get rid of it as well. > > But, I'm a little sad to see it go... :-( > I'll probably never see Linux on a cereal box. Oh there's plenty of people doing good work. I talk to Jeff Dionne daily, he's working on that sort of thing. I email Elliott Hughes (basically the android maintainer) multiple times per week. I talk to Rich Felker by voice every week (we're on the same wednesday call), and email or irc more often. (I feel guilty about dragging Elliott and Rich into https://www.mail-archive.com/austin-group-l@opengroup.org/msg08569.html because I underestimated the amount of bikeshedding on a list that's primarily posts from the bug tracker and meeting announcements/minutes.) None of them particularly participate in linux-kernel (despite Rich being arch/sh maintainer, and yes I poke him about that every wednesday) because that community comes across to us outsiders as a toxic insular clique that does not remotely understand any of our needs, and acts threatened if we try to explain them. Not because we CAN'T, but because it DOESN'T HELP WHEN WE TRY. I'm the one who's considered weird for still (occasionally) engaging. Mostly as bug reports like the above, or patches I post so when somebody sues I can go "here it is in the list archives, not my fault they didn't merge it", or one-offs I expect to be ignored (ala http://lkml.iu.edu/hypermail/linux/kernel/2110.1/03713.html) although sometimes there's a discussion that peters out without resolution instead (ala http://lkml.iu.edu/hypermail/linux/kernel/2110.1/09327.html). *shrug* Just stubborn I guess. > -- Tim Rob
On Sun, Oct 24, 2021 at 02:24:48AM -0500, Rob Landley wrote: > > The linux-embedded mailing list was created about the same time. > > The thinking was that there are issues that transcend any particular > > sub-system, directory, or file, such as boot time or system size or > > real-time. Changes to keep these system-wide metrics in check might > > need the assistance of a respected upstream maintainer, who could > > guide developers working in these areas, or who could help keep > > other kernel maintainers apprised of requirements in these areas > > for embedded products. > > Greg KH wouldn't listen to me when I was Documention maintainer. He wouldn't > listen when I was busybox maintainer. Maintainer-without-portfolio ain't gonna > get him to start. > > Keep in mind Greg and Kay Sievers were joined at the hip until Linus threw Kay > out of Linux dev and he bogged off to systemd. If you point out things like > "sysfs should to present a stable API to userspace" or "it's a bad idea to > depend on magic packages like udev or systemd as things every Linux system must > not only use verbatim from a single upstream supplier but must replace every > time they upgrade the kernel", Greg is reliably against them. I love you Rob, but I have no idea how the creation of mdev has anything to do with the topic at hand. Best of luck! greg k-h
On 9/20/2021 1:06 AM, Uwe Kleine-König wrote: > The mails I sent to Matt on September 14 and 20 both were refused by the > MTA responsible for selenic.com (i.e. waste.org) with: > > 554 5.7.1 <mpm@selenic.com>: Recipient address rejected: This identity is obsolete > > Also the most recent commit that involved him (ignoring "Cc: Matt > Mackall <mpm@selenic.com>" footers) is commit 330e0a01d54c (MAINTAINERS: > Theodore Ts'o is taking over the random driver) where he was removed > from the entry for random number drivers in 2012. > > So drop him completely from the list of maintainers. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> This has not been applied and we still have entries in MAINTAINERS that are bouncing for mpm@selenic.com, can we apply this patch?
diff --git a/MAINTAINERS b/MAINTAINERS index d7b4f32875a9..805630c67a1f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6812,7 +6812,6 @@ F: drivers/media/usb/em28xx/ EMBEDDED LINUX M: Paul Gortmaker <paul.gortmaker@windriver.com> -M: Matt Mackall <mpm@selenic.com> M: David Woodhouse <dwmw2@infradead.org> L: linux-embedded@vger.kernel.org S: Maintained @@ -8157,7 +8156,6 @@ F: include/trace/events/hwmon*.h K: (devm_)?hwmon_device_(un)?register(|_with_groups|_with_info) HARDWARE RANDOM NUMBER GENERATOR CORE -M: Matt Mackall <mpm@selenic.com> M: Herbert Xu <herbert@gondor.apana.org.au> L: linux-crypto@vger.kernel.org S: Odd fixes
The mails I sent to Matt on September 14 and 20 both were refused by the MTA responsible for selenic.com (i.e. waste.org) with: 554 5.7.1 <mpm@selenic.com>: Recipient address rejected: This identity is obsolete Also the most recent commit that involved him (ignoring "Cc: Matt Mackall <mpm@selenic.com>" footers) is commit 330e0a01d54c (MAINTAINERS: Theodore Ts'o is taking over the random driver) where he was removed from the entry for random number drivers in 2012. So drop him completely from the list of maintainers. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-)