From: Krzysztof Kozlowski <krzk@kernel.org>
To: Dave Airlie <airlied@gmail.com>, Mark Brown <broonie@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
"Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?
Date: Wed, 12 Aug 2026 08:00:59 +0200 [thread overview]
Message-ID: <0c95dc03-5b33-49aa-8368-bac482b8b40e@kernel.org> (raw)
In-Reply-To: <CAPM=9twB=hJURcbdaiDZjkEeUHTLmOLAoxnD+g0zGTTMq3nySw@mail.gmail.com>
On 11/08/2026 05:29, Dave Airlie wrote:
>>>> 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?
>>
>>> I guess the question is, what exactly is being big for DRM that it needs to do
>>> cherry-picking for their linux-next branch whereas Networking and ARM do
>>> not? Is DRM bigger than either of those? From what I understand VFS doesn't
>>> have to do that either. And VFS has a large range of file systems to deal
>>> with. But it also has one of the best abstraction layers of the kernel.
>>
>> It's not even all of DRM, it's specifically the AMD and Intel driver
>> stacks which as far as I can tell just routinely cherry pick all their
>> fixes between their development and fixes branches without even
>> considering the possibility of either merging up the fixes branch or
>> just waiting and letting the fixes propagate back. None of the rest of
>> the DRM trees ever seems to cause these issues.
>
> AMD and Intel are just the two largest teams with the longest
> pipelines of internal engineers and teams. There are between 50 and
> 100 people in those groups, across multiple disjoint teams feeding
> into a single driver. It just doesn't scale for all 50-100 people to
> understand the cycle of the upstream Linus tree at all times for all
> patches.
Qualcomm has also between 50-100 people in different teams upstreaming
to similar subsystems (like SoC) and they try to understand the cycle.
It's just AMD and Intel do not care to understand, because it is easier
for them and no one nags them...
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-08-12 6:01 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 15:34 [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit? James Bottomley
2026-08-06 23:41 ` Steven Rostedt
2026-08-07 13:53 ` Rafael J. Wysocki (Intel)
2026-08-07 14:53 ` Steven Rostedt
2026-08-07 16:33 ` James Bottomley
2026-08-07 17:27 ` Linus Torvalds
2026-08-07 19:03 ` James Bottomley
2026-08-07 19:51 ` Steven Rostedt
2026-08-07 20:12 ` Shuah Khan
2026-08-09 1:51 ` Theodore Tso
2026-08-09 18:47 ` Randy Dunlap
2026-08-09 19:04 ` Jonathan Corbet
2026-08-09 21:09 ` Steven Rostedt
2026-08-10 8:14 ` Lorenzo Stoakes (ARM)
2026-08-10 13:20 ` Steven Rostedt
2026-08-10 20:35 ` Liam R. Howlett
2026-08-10 21:05 ` Steven Rostedt
2026-08-11 0:14 ` Theodore Tso
2026-08-09 21:56 ` Liam R. Howlett
2026-08-10 1:26 ` Theodore Tso
2026-08-10 2:40 ` Liam R. Howlett
2026-08-10 8:08 ` Lorenzo Stoakes (ARM)
2026-08-10 14:56 ` Theodore Tso
2026-08-10 15:49 ` Lorenzo Stoakes (ARM)
2026-08-09 18:39 ` Lorenzo Stoakes (ARM)
2026-08-09 18:42 ` Lorenzo Stoakes (ARM)
2026-08-09 22:10 ` Dave Airlie
2026-08-10 7:26 ` Lorenzo Stoakes (ARM)
2026-08-10 13:11 ` Steven Rostedt
2026-08-10 13:32 ` James Bottomley
2026-08-10 14:24 ` Steven Rostedt
2026-08-10 15:23 ` Mark Brown
2026-08-10 15:52 ` Randy Dunlap
2026-08-11 3:24 ` Dave Airlie
2026-08-11 5:29 ` Randy Dunlap
2026-08-11 6:53 ` Geert Uytterhoeven
2026-08-11 13:29 ` Mark Brown
2026-08-10 22:47 ` Mark Brown
2026-08-11 8:12 ` Dup commits in NFC trees [Was: Time to call it quits for the maintainer summit?] Matthieu Baerts
2026-08-11 13:17 ` Mark Brown
2026-08-11 16:39 ` David Heidelberg
2026-08-11 16:58 ` Mark Brown
2026-08-11 3:29 ` [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit? Dave Airlie
2026-08-11 7:12 ` Geert Uytterhoeven
2026-08-11 8:16 ` Geert Uytterhoeven
2026-08-11 19:54 ` Rodrigo Vivi
2026-08-11 23:10 ` Mark Brown
2026-08-11 14:26 ` Mark Brown
2026-08-12 6:00 ` Krzysztof Kozlowski [this message]
2026-08-12 6:20 ` Dave Airlie
2026-08-12 7:07 ` Krzysztof Kozlowski
2026-08-12 7:41 ` Greg KH
2026-08-12 8:05 ` Dave Airlie
2026-08-12 12:48 ` Mark Brown
2026-08-10 21:30 ` Dave Airlie
2026-08-10 21:45 ` Liam R. Howlett
2026-08-11 8:22 ` Lorenzo Stoakes (ARM)
2026-08-11 8:19 ` Lorenzo Stoakes (ARM)
2026-08-11 9:06 ` Jiri Kosina
2026-08-11 9:34 ` Dave Airlie
2026-08-11 13:47 ` Steven Rostedt
2026-08-10 7:42 ` Geert Uytterhoeven
2026-08-10 15:07 ` Theodore Tso
2026-08-07 12:58 ` Laurent Pinchart
2026-08-07 13:09 ` James Bottomley
2026-08-07 13:28 ` Laurent Pinchart
2026-08-07 20:15 ` H. Peter Anvin
2026-08-07 19:15 ` Chris Mason
2026-08-07 19:53 ` Steven Rostedt
2026-08-07 23:19 ` Theodore Tso
2026-08-10 13:54 ` James Bottomley
2026-08-10 14:41 ` Steven Rostedt
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=0c95dc03-5b33-49aa-8368-bac482b8b40e@kernel.org \
--to=krzk@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=airlied@gmail.com \
--cc=broonie@kernel.org \
--cc=ksummit@lists.linux.dev \
--cc=ljs@kernel.org \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.