Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?
James Bottomley <[email protected]>
| Newsgroups | dev.linux.lists.ksummit |
|---|---|
| Message-ID | <cc6505e586325cd59ba036cef5429039c9c71ba8.camel@HansenPartnership.com> |
On Mon, 2026-08-10 at 09:11 -0400, Steven Rostedt wrote: > On Mon, 10 Aug 2026 08:26:36 +0100 > "Lorenzo Stoakes (ARM)" <[email protected]> wrote: > > > > Voting on what though, I'm already over the number of times > > > maintainers with small potato problems think that the lives of > > > maintainers with big potato problems would be much simpler if > > > they > > > just adopted their niche one-person mutt based review process. > > > > Ah good to know core mm is small potatoes ;) > > From my understanding of what Dave ranted about last time, MM would > be small potatoes. > > I think it's because DRM has a wide arrangement of different types of > hardware under one umbrella. It sounded to me a bit like herding > cats. > > MM may be a large and critical subsystem, but most hardware acts > pretty much the same. Have you met some of the weird architectures with their super strange VM extensions and the even weirder confidential computing extensions? > Where most developers are working together on a common > platform. Even with minor differences between architectures. > Architecture specifics of how to create memory mappings can be mostly > be abstracted out. True (well mostly), but the internal complexity is concealed within an external abstraction rather than having it spill all over the kernel ... I would hope DRM does the same. > I don't know DRM at all, but just from listening to Dave, it sounded > to me like everyone is doing things their own way and Dave needs to > manage it all with a more complex process. Where networking and arm > may be the only ones to rival the complex process of DRM. If your assumption is correct, this is internal cat herding ... MM has much the same problem except that it has to deal with somewhat opinionated architecture maintainers (around 22 of them) to agree on the internal abstractions for MM primitives. Perhaps rather than getting into my problem is bigger than yours type arguments, we could observe that MM might run a bit more smoothly because it gets an additional 3 day conference (LSF/MM) plus a MC at Plumbers to sort itself out? Regards, James