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 <[email protected]>: Recipient address rejected: This identity is obsolete
Also the most recent commit that involved him (ignoring "Cc: Matt
Mackall <[email protected]>" 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 <[email protected]>
---
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 <[email protected]>
-M: Matt Mackall <[email protected]>
M: David Woodhouse <[email protected]>
L: [email protected]
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 <[email protected]>
M: Herbert Xu <[email protected]>
L: [email protected]
S: Odd fixes
--
2.30.2
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
> <[email protected]> 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 <[email protected]>: Recipient address rejected: This identity is obsolete
> >
> > Also the most recent commit that involved him (ignoring "Cc: Matt
> > Mackall <[email protected]>" 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 <[email protected]>
> > ---
> > 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 <[email protected]>
> > -M: Matt Mackall <[email protected]>
>
> Perhaps this should be replaced by
> "Olivia Mackall <[email protected]>" 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
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
On Tue, Oct 19, 2021 at 11:48 AM Laurent Pinchart
<[email protected]> 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 -- [email protected]
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 <[email protected]> writes:
> On Tue, Oct 19, 2021 at 11:48 AM Laurent Pinchart
> <[email protected]> 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
On 10/19/21 5:54 PM, [email protected] 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/[email protected]/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