From: <Tim.Bird@sony.com> To: <email@example.com>, <firstname.lastname@example.org>, <email@example.com> Cc: <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>, <email@example.com> Subject: RE: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete Date: Tue, 19 Oct 2021 22:54:01 +0000 [thread overview] Message-ID: <BYAPR13MB250310153BF63EF3ED50F294FDBD9@BYAPR13MB2503.namprd13.prod.outlook.com> (raw) In-Reply-To: <firstname.lastname@example.org> > -----Original Message----- > From: Kevin Hilman <email@example.com> > > Geert Uytterhoeven <firstname.lastname@example.org> writes: > > > On Tue, Oct 19, 2021 at 11:48 AM Laurent Pinchart > > <email@example.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
next prev parent reply other threads:[~2021-10-20 0:28 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-20 8:06 Uwe Kleine-König 2021-09-20 13:01 ` Geert Uytterhoeven 2021-09-23 18:51 ` Uwe Kleine-König [not found] ` <CA+bK7J741D=DgZMNeEC5xg9kDDSaJu19QsRunVvXkBGx1mKGnQ@mail.gmail.com> 2021-10-19 6:55 ` Laurent Pinchart 2021-10-19 9:33 ` David Woodhouse 2021-10-19 9:47 ` Laurent Pinchart 2021-10-19 9:56 ` Geert Uytterhoeven 2021-10-19 22:24 ` Kevin Hilman 2021-10-19 22:54 ` Tim.Bird [this message] 2021-10-24 7:24 ` Rob Landley 2021-10-24 9:57 ` Greg KH
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=BYAPR13MB250310153BF63EF3ED50F294FDBD9@BYAPR13MB2503.namprd13.prod.outlook.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='RE: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete' \ /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
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.