[MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[James Bottomley]

What got me thinking about this is the obvious funding problem: MS is
free to attendees, but only had one sponsor in 2024, none in 2025 and
is on track to have none this year. Since Plumbers has a reasonably
successful sponsor model and the LF brought the problem up in recent
conversations, we thought we'd take a look.  A colleague remarked that
it should be easy to sell seats to a room with Linus, which on the face
of it looks to be true, but when examined more deeply isn't
straighforward.  The problem is conferences like Plumbers, LSF/MM and
MS are usually sponsored by engineering not marketing where budget is
much harder to come by and the justification for ponying up the cash
has to be very clear; effectively they pay for outcomes not access or
publicity (although access is required to get successful outcomes). 
When you look at the actual outcomes of MS 2025

https://lwn.net/Articles/1049982/

there isn't really anything that would move the needle for a potential
sponsor.  Equally, there's nothing really that couldn't have been part
of a wider discussion at Plumbers or LSF/MM, so I'm not sure there's
anything that actually required discussion at this event (i.e. nothing
to move the needle for kernel developers either).

Before I go into potential solutions, it might be beneficial to review
the history:  The kernel summit began as a stand alone event in 2001
run by USENIX and was the first time many kernel developers had
actually met each other. It continued as a 2 day event co-located with
Ottawa Linux Symposium (still run by USENIX) until 2008 when it mostly
co-located with Plumbers and was run by the LF.  In 2015 Linus
complained that he didn't find the KS talks that valuable and he'd like
to discuss process with a smaller audience, so in 2016 the kernel
summit was split and the talks went to the kernel summit track in
Plumbers and a 1 day Maintainer Summit was born.  It can be argued that
the decline in sponsors began with the 2016 split and thus, as the
sponsors apparently see it, the decline in outcomes as well.  Oh and
for those of you who keep saying the LF doesn't fund Linux: without
sponsors the LF is eating the cost of the entire event which, based on
what Plumbers costs, will be somewhere north of US$100k.

As for fixes, one possibility is definitely keeping MS as is and moving
the sponsor responsibility to Plumbers, but unless I can strap Linus
down and sell companies on pitching to him directly, I fear that would
end up creating a US$100k hole in our budget.  Perhaps there are
actually outcomes we could sell to sponsors but, because of the reduced
audience, we simply don't get to hear about them ... so if you think
that now would be the time to say what they are.  Another solution that
seems viable would be folding the MS into one of our existing sponsored
events, like Plumbers or LSF/MM.  Structurally either would be a fit
for the past discussion topics and both could probably accommodate
(although I don't think either could expand to a fourth day to do it).
A final thing we might do is change the structure of the event itself
to have more sponsorable outcomes; perhaps simply making the event more
like the kernel summit of old, so moving back the KS track from
Plumbers would be enough?

Regards,

James

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Steven Rostedt]

On Thu, 06 Aug 2026 11:34:09 -0400
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:


> 
> there isn't really anything that would move the needle for a potential
> sponsor.  Equally, there's nothing really that couldn't have been part
> of a wider discussion at Plumbers or LSF/MM, so I'm not sure there's
> anything that actually required discussion at this event (i.e. nothing
> to move the needle for kernel developers either).

Well, I'm guessing that AI will be a big topic this year at MS. That alone
may drive up sponsorship! If the AI bubble doesn't pop before then, all we
need to do is market MS as an gathering of those that will influence AI on
the Linux kernel. ;-)


> As for fixes, one possibility is definitely keeping MS as is and moving
> the sponsor responsibility to Plumbers, but unless I can strap Linus
> down and sell companies on pitching to him directly, I fear that would
> end up creating a US$100k hole in our budget.  Perhaps there are
> actually outcomes we could sell to sponsors but, because of the reduced
> audience, we simply don't get to hear about them ... so if you think
> that now would be the time to say what they are.  Another solution that
> seems viable would be folding the MS into one of our existing sponsored
> events, like Plumbers or LSF/MM.  Structurally either would be a fit
> for the past discussion topics and both could probably accommodate
> (although I don't think either could expand to a fourth day to do it).
> A final thing we might do is change the structure of the event itself
> to have more sponsorable outcomes; perhaps simply making the event more
> like the kernel summit of old, so moving back the KS track from
> Plumbers would be enough?

I guess it really comes down to what Linus wants. He's been saying he would
love to get rid of Kernel/Maintainers Summit for years. Does Linus still
find it useful? It is still good to have the more controversial topics done
face to face and allow Linus to listen in. I've been saying he needs to
interact more with the general community given the number of times he told
me that "nobody does that" when I'm hearing from talking with people at
conferences that several people do do that.

Thus, I still think it is good to find a way to make Linus do what he loves
and interact with his fellow developers ;-)  But perhaps it's time to
rethink the format and restructure it once again.

-- Steve

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Laurent Pinchart]

On Thu, Aug 06, 2026 at 11:34:09AM -0400, James Bottomley wrote:
> What got me thinking about this is the obvious funding problem: MS is
> free to attendees, but only had one sponsor in 2024, none in 2025 and
> is on track to have none this year.

The sponsorship prospectus ([1]) indicates that the "attendee gift"
category is sold out, does it mean one sponsor signed up ?

[1] https://events.linuxfoundation.org/wp-content/uploads/2026/08/sponsor-kernel26_080626.pdf

> Since Plumbers has a reasonably
> successful sponsor model and the LF brought the problem up in recent
> conversations, we thought we'd take a look.  A colleague remarked that
> it should be easy to sell seats to a room with Linus, which on the face
> of it looks to be true, but when examined more deeply isn't
> straighforward.  The problem is conferences like Plumbers, LSF/MM and
> MS are usually sponsored by engineering not marketing where budget is
> much harder to come by and the justification for ponying up the cash
> has to be very clear; effectively they pay for outcomes not access or
> publicity (although access is required to get successful outcomes). 
> When you look at the actual outcomes of MS 2025
> 
> https://lwn.net/Articles/1049982/
> 
> there isn't really anything that would move the needle for a potential
> sponsor.  Equally, there's nothing really that couldn't have been part
> of a wider discussion at Plumbers or LSF/MM, so I'm not sure there's
> anything that actually required discussion at this event (i.e. nothing
> to move the needle for kernel developers either).
> 
> Before I go into potential solutions, it might be beneficial to review
> the history:  The kernel summit began as a stand alone event in 2001
> run by USENIX and was the first time many kernel developers had
> actually met each other. It continued as a 2 day event co-located with
> Ottawa Linux Symposium (still run by USENIX) until 2008 when it mostly
> co-located with Plumbers and was run by the LF.  In 2015 Linus
> complained that he didn't find the KS talks that valuable and he'd like
> to discuss process with a smaller audience, so in 2016 the kernel
> summit was split and the talks went to the kernel summit track in
> Plumbers and a 1 day Maintainer Summit was born.  It can be argued that
> the decline in sponsors began with the 2016 split and thus, as the
> sponsors apparently see it, the decline in outcomes as well.  Oh and
> for those of you who keep saying the LF doesn't fund Linux: without
> sponsors the LF is eating the cost of the entire event which, based on
> what Plumbers costs, will be somewhere north of US$100k.
> 
> As for fixes, one possibility is definitely keeping MS as is and moving
> the sponsor responsibility to Plumbers, but unless I can strap Linus
> down and sell companies on pitching to him directly, I fear that would
> end up creating a US$100k hole in our budget.  Perhaps there are
> actually outcomes we could sell to sponsors but, because of the reduced
> audience, we simply don't get to hear about them ... so if you think
> that now would be the time to say what they are.  Another solution that
> seems viable would be folding the MS into one of our existing sponsored
> events, like Plumbers or LSF/MM.  Structurally either would be a fit
> for the past discussion topics and both could probably accommodate
> (although I don't think either could expand to a fourth day to do it).
> A final thing we might do is change the structure of the event itself
> to have more sponsorable outcomes; perhaps simply making the event more
> like the kernel summit of old, so moving back the KS track from
> Plumbers would be enough?

The maintainer summit is limited to 30 guests, plus up to 7 sponsored
attendee according to [1]. Assuming neither Linus nor the program
committee are counted as guests, that would be 43 people in total, so a
rough cost of $2500 per person for one day. I understand that hosting
events in large venues is expensive, but if the maintainer summit is an
invite-only, separate event, would it be an option to drastically cut
costs by hosting it in a nearby but separate location ?

-- 
Regards,

Laurent Pinchart

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[James Bottomley]

On Fri, 2026-08-07 at 15:58 +0300, Laurent Pinchart wrote:
> On Thu, Aug 06, 2026 at 11:34:09AM -0400, James Bottomley wrote:
> > What got me thinking about this is the obvious funding problem: MS
> > is free to attendees, but only had one sponsor in 2024, none in
> > 2025 and is on track to have none this year.
> 
> The sponsorship prospectus ([1]) indicates that the "attendee gift"
> category is sold out, does it mean one sponsor signed up ?

The LF paid for the attendee gift last year. Since they have to be
ordered some way ahead of the conference I'd guess the same is true
this year.

[...]
> The maintainer summit is limited to 30 guests, plus up to 7 sponsored
> attendee according to [1]. Assuming neither Linus nor the program
> committee are counted as guests, that would be 43 people in total, so
> a rough cost of $2500 per person for one day. 

I take it you've never seen the bill for attending a USENIX (or a lot
of other) one day events.

> I understand that hosting events in large venues is expensive, but if
> the maintainer summit is an invite-only, separate event, would it be
> an option to drastically cut costs by hosting it in a nearby but
> separate location ?

Is there any point wittering about your speculated numbers vs mine? 
The bottom line is there is a cost and someone has to pay it if there
are no sponsors.

Regards,

James

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Laurent Pinchart]

On Fri, Aug 07, 2026 at 09:09:05AM -0400, James Bottomley wrote:
> On Fri, 2026-08-07 at 15:58 +0300, Laurent Pinchart wrote:
> > On Thu, Aug 06, 2026 at 11:34:09AM -0400, James Bottomley wrote:
> > > What got me thinking about this is the obvious funding problem: MS
> > > is free to attendees, but only had one sponsor in 2024, none in
> > > 2025 and is on track to have none this year.
> > 
> > The sponsorship prospectus ([1]) indicates that the "attendee gift"
> > category is sold out, does it mean one sponsor signed up ?
> 
> The LF paid for the attendee gift last year. Since they have to be
> ordered some way ahead of the conference I'd guess the same is true
> this year.
> 
> [...]
> 
> > The maintainer summit is limited to 30 guests, plus up to 7 sponsored
> > attendee according to [1]. Assuming neither Linus nor the program
> > committee are counted as guests, that would be 43 people in total, so
> > a rough cost of $2500 per person for one day. 
> 
> I take it you've never seen the bill for attending a USENIX (or a lot
> of other) one day events.

USENIX, no. That was unfortunately before my days.

> > I understand that hosting events in large venues is expensive, but if
> > the maintainer summit is an invite-only, separate event, would it be
> > an option to drastically cut costs by hosting it in a nearby but
> > separate location ?
> 
> Is there any point wittering about your speculated numbers vs mine? 
> The bottom line is there is a cost and someone has to pay it if there
> are no sponsors.

Please don't speculate that I'm speculating. I've organized multiple
one-day events for crowds between 15 and 25 people, at costs of around
100€ per attendee for a meeting room and lunch. I know it doesn't scale
linearly, and I'm sure we don't want to organize the maintainers summit
at the lowest possible cost, but there's quite a gap.

-- 
Regards,

Laurent Pinchart

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Rafael J. Wysocki (Intel)]

On Fri, Aug 7, 2026 at 1:41 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Thu, 06 Aug 2026 11:34:09 -0400
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
>
> >
> > there isn't really anything that would move the needle for a potential
> > sponsor.  Equally, there's nothing really that couldn't have been part
> > of a wider discussion at Plumbers or LSF/MM, so I'm not sure there's
> > anything that actually required discussion at this event (i.e. nothing
> > to move the needle for kernel developers either).
>
> Well, I'm guessing that AI will be a big topic this year at MS. That alone
> may drive up sponsorship! If the AI bubble doesn't pop before then, all we
> need to do is market MS as an gathering of those that will influence AI on
> the Linux kernel. ;-)
>
>
> > As for fixes, one possibility is definitely keeping MS as is and moving
> > the sponsor responsibility to Plumbers, but unless I can strap Linus
> > down and sell companies on pitching to him directly, I fear that would
> > end up creating a US$100k hole in our budget.  Perhaps there are
> > actually outcomes we could sell to sponsors but, because of the reduced
> > audience, we simply don't get to hear about them ... so if you think
> > that now would be the time to say what they are.  Another solution that
> > seems viable would be folding the MS into one of our existing sponsored
> > events, like Plumbers or LSF/MM.  Structurally either would be a fit
> > for the past discussion topics and both could probably accommodate
> > (although I don't think either could expand to a fourth day to do it).
> > A final thing we might do is change the structure of the event itself
> > to have more sponsorable outcomes; perhaps simply making the event more
> > like the kernel summit of old, so moving back the KS track from
> > Plumbers would be enough?
>
> I guess it really comes down to what Linus wants. He's been saying he would
> love to get rid of Kernel/Maintainers Summit for years. Does Linus still
> find it useful? It is still good to have the more controversial topics done
> face to face and allow Linus to listen in. I've been saying he needs to
> interact more with the general community given the number of times he told
> me that "nobody does that" when I'm hearing from talking with people at
> conferences that several people do do that.
>
> Thus, I still think it is good to find a way to make Linus do what he loves
> and interact with his fellow developers ;-)  But perhaps it's time to
> rethink the format and restructure it once again.

Please note though that Maintainer Summit now plays a more formal role
in the project due to Documentation/process/conclave.rst, so if the
format is changed substantially, it may also call for an update of
that contingency plan.

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Steven Rostedt]

On Fri, 7 Aug 2026 15:53:57 +0200
"Rafael J. Wysocki (Intel)" <rafael@kernel.org> wrote:

> > Thus, I still think it is good to find a way to make Linus do what he loves
> > and interact with his fellow developers ;-)  But perhaps it's time to
> > rethink the format and restructure it once again.  
> 
> Please note though that Maintainer Summit now plays a more formal role
> in the project due to Documentation/process/conclave.rst, so if the
> format is changed substantially, it may also call for an update of
> that contingency plan.

Good point. And I think that should also be looked at more thoroughly and
come up with something perhaps more concrete than a plan to create a plan.

-- Steve

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[James Bottomley]

On Fri, 2026-08-07 at 15:53 +0200, Rafael J. Wysocki (Intel) wrote:
[...]
> Please note though that Maintainer Summit now plays a more formal
> role in the project due to Documentation/process/conclave.rst, so if
> the format is changed substantially, it may also call for an update
> of that contingency plan.

If you analyse that document for the worst case outcome (no separate
Maintainer Summit) and ask what does it say we should do it says TAB
chair should become $ORGANIZER (instead of MS organizer) and the TAB
will pick the attendees for the succession meeting.

That's not to say we shouldn't update the process, but to point out the
contingency is actually covered in the existing document.

Regards,

James

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Linus Torvalds]

On Thu, 6 Aug 2026 at 16:50, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> I guess it really comes down to what Linus wants. He's been saying he would
> love to get rid of Kernel/Maintainers Summit for years.

So as you say, I don't love it. The original kernel summits way back
when was great and I enjoyed it a lot - but that was a *long* time ago
and the scopes were smaller and I think the problems were smaller too.

We had technical issues that were universally interesting.

Then the developer community grew and it became less universal with
the technical discussions often really just being cliques where some
developers were interested in particular issues and others that
"checked out" of that part entirely.

The maintainer summit was an attempt at keeping it focused on pure
maintainership questions, and keeping technical discussions that don't
cross maintainership borders in email or targeted miniconferences and
the like.

And it *works* in that sense, and I think it has been useful, but I
have to admit to still feeling like it's not wonderful.

For example, I keep generating the partial list of people that I think
should be part of it, and honestly, for the last few years it has been
a very similar list every time.

Which is fine and a measure of reality: it's not like the main
maintainers have changed very much - but it still makes me just think
it's also just a bit staid.

To explain that last point: back in the olden days, when we lived in
caves and communicated by grunts and gestures, and I still lived in
Helsinki and knew basically _none_ of the developers personally, I
felt that the Linux community was in fact a bit more "open" to people
because we didn't have this whole tightly knit community of old-timers
that the BSD's had, or the physical closeness that some other projects
had with all the developers actually meeting in person.

And I thought that was a good thing. No "in-group" behavior.

The maintainer summit being a pretty constant "in-group" is
fundamental, but it still feels a bit sad and wrong to me.

I do think we have things to discuss this year, but I do also think
this is a good subject to discuss.

               Linus

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[James Bottomley]

On Fri, 2026-08-07 at 10:27 -0700, Linus Torvalds wrote:
> On Thu, 6 Aug 2026 at 16:50, Steven Rostedt <rostedt@goodmis.org>
> wrote:
> > 
> > I guess it really comes down to what Linus wants. He's been saying
> > he would love to get rid of Kernel/Maintainers Summit for years.
> 
> So as you say, I don't love it. The original kernel summits way back
> when was great and I enjoyed it a lot - but that was a *long* time
> ago and the scopes were smaller and I think the problems were smaller
> too.
> 
> We had technical issues that were universally interesting.
> 
> Then the developer community grew and it became less universal with
> the technical discussions often really just being cliques where some
> developers were interested in particular issues and others that
> "checked out" of that part entirely.
> 
> The maintainer summit was an attempt at keeping it focused on pure
> maintainership questions, and keeping technical discussions that
> don't cross maintainership borders in email or targeted
> miniconferences and the like.
> 
> And it *works* in that sense, and I think it has been useful, but I
> have to admit to still feeling like it's not wonderful.
> 
> For example, I keep generating the partial list of people that I
> think should be part of it, and honestly, for the last few years it
> has been a very similar list every time.

So this sounds like part of the problem: if you always generate the
same list of people you're going to get the same ideas coming around. 
If you want different ideas and perspectives you need diversity of
views in some form ... I get you said "partial" but if the rest of that
partial is pretty much the same too, then there's a definitely sameness
problem with the selection process.

> Which is fine and a measure of reality: it's not like the main
> maintainers have changed very much - but it still makes me just think
> it's also just a bit staid.
> 
> To explain that last point: back in the olden days, when we lived in
> caves and communicated by grunts and gestures, and I still lived in
> Helsinki and knew basically _none_ of the developers personally, I
> felt that the Linux community was in fact a bit more "open" to people
> because we didn't have this whole tightly knit community of old-
> timers that the BSD's had, or the physical closeness that some other
> projects had with all the developers actually meeting in person.
> 
> And I thought that was a good thing. No "in-group" behavior.
> 
> The maintainer summit being a pretty constant "in-group" is
> fundamental, but it still feels a bit sad and wrong to me.

Effectively you've made it a Leadership Team (LT) meeting and actually
the conclave.rst thing pretty much embeds that because it seems to be
founded on the idea that the maintainer summit represents the
leadership.

Just going on the Plumbers experience, I do think the problem sounds
like it has shrunk too far (you do need a certain number in a room just
to get discussion going properly).  You don't need to expand it up to
the 100 or so people it was, but it really sounds like you do need a
little expansion.

In industry generally, there's often a concept of XLT (expanded
leadership team), which means you invite some of your skip levels and
general contrarians and other individual contributors in to shake up
the perspective a little.  So perhaps expanding from ~34 to ~54 and
allocating 20 places for less well known maintainers and possibly even
new people.  This could be as simple as giving instructions to the
other bit of the selection to look for people who would express
differing viewpoints and generate useful debate.

Incidentally, if you wanted to raffle off the expanded places in some
sort of buy a lottery ticket or buy a sponsorship scheme, we might be
able to make that work as a funding model.

Regards,

James

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Chris Mason]

On Thu, Aug 6, 2026 at 11:35 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> What got me thinking about this is the obvious funding problem: MS is
> free to attendees, but only had one sponsor in 2024, none in 2025 and
> is on track to have none this year. Since Plumbers has a reasonably
> successful sponsor model and the LF brought the problem up in recent
> conversations, we thought we'd take a look.

[ ... ]

> without
> sponsors the LF is eating the cost of the entire event which, based on
> what Plumbers costs, will be somewhere north of US$100k.
>

Lots of removed context, but I wanted to focus on the urgent topic
first.  I was concerned that the maintainer summit might not have the
funding it needs for 2026 and beyond.

Before twisting internal arms, I asked Angela Brown what MS costs
today and whether the LF felt short-term or long-term structural
changes were needed to continue supporting the event.  The answers
were ~$25K and that no changes are needed for the Linux Foundation to
continue supporting the maintainer summit in its current form.

Another bit of context I removed (please forgive my paraphrasing) was
the idea that MS sponsorship can't be justified based on the outcomes.
I don't think this is true, our respective companies frequently fund
internal leadership summits.  We'd need to be intentional about
finding the sponsors, but the price is fairly reasonable and the
engineering benefits are quite high.

I think the more interesting question is how we ensure MS continues to
provide value to Linus and the maintainers.  Hopefully we can answer
that first and then figure out how to fund things after.

From my slightly-outsider point of view, it's a synchronization point
where we can pin each other down and resolve long standing debates.
And also AI, we can talk about AI.

-chris

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Steven Rostedt]

On Fri, 7 Aug 2026 10:27:27 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> The maintainer summit being a pretty constant "in-group" is
> fundamental, but it still feels a bit sad and wrong to me.

That's because Linux has matured quite a bit. In any project or even
company that has been around for a long time, you will see those that have
been around for the longest time become a common participant in leadership
meetings. It makes sense as those same people likely have the most
experience.

But we do have new blood when new things start to appear. Look at Miguel
Ojeda for example. He was the one to push Rust into the kernel and now even
though he's a relatively new (and young) maintainer, he's becoming one of
those "in-group" participants.  This to me shows that we do encourage new
people to join the leadership ranks when it makes sense.

And I expect that soon (in 5 years) we'll likely start seeing more of the
top maintainers start to back off and let others take over. Andrew Morton
has recently posted that he's entering that process. I suspect that those
of us in our 50s and older will be looking for new blood to fill our shoes.
I'm already starting to look for myself ;-) (Although, I'm not ready to
retire, I have that feeling I need to find others to do what I do).

-- Steve

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Steven Rostedt]

On Fri, 7 Aug 2026 15:15:08 -0400
Chris Mason <clm@meta.com> wrote:

> And also AI, we can talk about AI.

I think we just solved our funding issue for this year ;-)

-- Steve

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Shuah Khan]

On 8/7/26 13:51, Steven Rostedt wrote:
> On Fri, 7 Aug 2026 10:27:27 -0700
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
>> The maintainer summit being a pretty constant "in-group" is
>> fundamental, but it still feels a bit sad and wrong to me.

The current format for MS is definitely more focused and easier
to discuss maintainership process and issues.

The larger format we had prior to the current one had some benefits
as it allowed wider participation compared to the current. I definitely
benefited from listening in on these discussions to get a feel for how
the community makes technical and process decisions when we had the
larger format.

MS PC continues to invite new developers though fewer probably compared
to the old format.

Maybe we could look into bringing that aspect back by making some
discussions wider and make that part of the kernel summit track.
It would become more important as the top maintainers reduce their
engagement overtime.
  
thanks,
-- Shuah

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[H. Peter Anvin]

On August 7, 2026 6:09:05 AM PDT, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>On Fri, 2026-08-07 at 15:58 +0300, Laurent Pinchart wrote:
>> On Thu, Aug 06, 2026 at 11:34:09AM -0400, James Bottomley wrote:
>> > What got me thinking about this is the obvious funding problem: MS
>> > is free to attendees, but only had one sponsor in 2024, none in
>> > 2025 and is on track to have none this year.
>> 
>> The sponsorship prospectus ([1]) indicates that the "attendee gift"
>> category is sold out, does it mean one sponsor signed up ?
>
>The LF paid for the attendee gift last year. Since they have to be
>ordered some way ahead of the conference I'd guess the same is true
>this year.
>
>[...]
>> The maintainer summit is limited to 30 guests, plus up to 7 sponsored
>> attendee according to [1]. Assuming neither Linus nor the program
>> committee are counted as guests, that would be 43 people in total, so
>> a rough cost of $2500 per person for one day. 
>
>I take it you've never seen the bill for attending a USENIX (or a lot
>of other) one day events.
>
>> I understand that hosting events in large venues is expensive, but if
>> the maintainer summit is an invite-only, separate event, would it be
>> an option to drastically cut costs by hosting it in a nearby but
>> separate location ?
>
>Is there any point wittering about your speculated numbers vs mine? 
>The bottom line is there is a cost and someone has to pay it if there
>are no sponsors.
>
>Regards,
>
>James
>
>

I think it is worth in all of this to consider the following somewhat bigger question: what are the things (not just events) that we cannot expect to be individually sponsor-covered in the long run? 

The whole mission of the LF is to provide funding for exactly these things through aggregate fundraising. 

To me, that comes in a few buckets: ongoing infrastructure (e.g. kernel.org), fellowships for senior architects like Linus and Greg, funding projects that are highly critical but not "glamourous", and urgent assistance (legal and financial) for members in the larger community when either something catastrophic happens (e.g. the xz disaster) or there is a brief opportunity window (we had a few day window for getting sparse relicensed; I had reached out to LF for legal assistance but never even heard back. In the end we had to wing it without any legal help.)

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Theodore Tso]

On Thu, Aug 06, 2026 at 11:34:09AM -0500, James Bottomley wrote:
> It continued as a 2 day event co-located with
> Ottawa Linux Symposium (still run by USENIX) until 2008 when it mostly
> co-located with Plumbers and was run by the LF.  In 2015 Linus
> complained that he didn't find the KS talks that valuable and he'd like
> to discuss process with a smaller audience, so in 2016 the kernel
> summit was split and the talks went to the kernel summit track in
> Plumbers and a 1 day Maintainer Summit was born.

When the Kernel Summit grew from ~50 people to a bit over 150 people,
it started getting a lot more unwieldy, and it became impossible to
make sure all of the people needed for a particular technical topic
could be issued invites.  The flip side was that when there was that
many people in the room, it was too hard to have focused process
discussions.

So that was the reason why the the split took place; it was getting
too large for process discussions, and it was too small for technical
discussions.

Today, the Maintainer Summit is basically a half-day event, with
around 30 people (plus any sponsored attendees), and is only focused
on process questions, with the technical discussions taking place at
the Plumbers Conference where it is colocated --- the miniconferences,
Refereed and Kernel Summit tracker, and the BOF's.  And I think that's
worked pretty well.

As such, the costs of the Maintainers Summit is actually pretty cheap,
especiallly since there is no A/V, and a room that can hold ~30 people
is not really that big of deal.  So I doubt it is as expensive as what
James has estimated.  If we did want to economize, we could do things
like drop the Kernel Summit dinner and the "sponsor gift".  I can talk
to the Linux Foundation to see what they are willing to fund, but
given some of the process discussions that have taken place such as
"The End of the Rust Experiment"[1], and the discussions around AI
that almost certianly will take place this year, I think the value
Maintainer Summit is one where hopefully the LF would be willing to
support it one way or another.

[1] https://lwn.net/Articles/1049831/


We can split this discussion a couple of different ways.  The first is
how can we make the Maintainers Summit more valuable.  I do think that
in the last couple of years, there *have* been a number of quite
valuable discussions, but it's always worthwhile to consider ways in
which we can improve the discussion.  So that's on the "benefits" side
of the equation.

The second is on the "costs" side of the equation.  There are a couple
of things, such as the dinner and the gift, that we can almost
certainly slim down, if this is becoming too much of a burden to the
LF.

Getting more sponsorship dollars is going to be challenging.
When we had the the technical content in the Kernel Summit as part of
the invite-only portion of the event, companies would pay $$$ because
they wanted to introduce specific technical ideas, to better support
their products because what they were paying for was the attention of
the Kernel Developers.  This "attention economy" dynamic is one of the
things that does still work and drives sponsorship with LSF/MM, by the
way.

						- Ted

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Theodore Tso]

On Fri, Aug 07, 2026 at 10:27:27AM -0500, Linus Torvalds wrote:
> The maintainer summit being a pretty constant "in-group" is
> fundamental, but it still feels a bit sad and wrong to me.

I was curious about the data, so I looked at the spreadsheets for the
last four Maintainers Summit (from 2022 to 2026) to see how many
people had attended all four Summits... or 3, or 2, or 1.  Here they
are:

# Summits
Attended   #      %
------------------------
4 	   9	18.37%
3          8	16.33%
2         10	20.41%
1         22	44.90%

I'll be honest; these numbers surprised me.  I can understand Linus's
statement about how it feels like it's pretty much the constant
"in-group", since I had the same feeling --- but it's much less of the
same "in group clique" than what I at least had expected.

Probably, some of it is that there is a certain set of biases and
thinking that comes from people who are "core maintainers" -- such
that even if 20% have only attended two out of the past 4 summits, and
45% have attended only 1 of the past summits, those attendees probably
approached our discussions the same way as someone who has been at all
of the past 4 summits.

If there are things that we could change in terms of how to make it be
less of an "in group", I think that would be a good thing to consider.
Should we invite people who might have a very different sets of
opinions --- for example, while Kent Overstreet was an in-tree
maintainer, should we have invited him?

And I'm only half-joking here, even though I would have found it
personally uncomfortable if Kent was at one of the Summits.  But
perhaps we *should* be a little uncomfortable.  Furthermore, one of my
original goals behind starting the kernel summit is that sometimes we
can work better together when we've broken bread over a shared meal
together.  That being given tht many of us had a chance to work with
Kent at LSF/MM/BPF and (I think) Plumbers, I'm not sure it would have
made that much different to what happened with the Kent situation.

As another thought, when we had 100+ people attending the Kernel
Summit, that we would make a *point* of inviting people who had never
attended Kernel Summits before, so we would get new blood attending
the Summit.  After we significantly reduced the the size of the
Maintainers Summit to 30, we've stopped doing this as a deliberate
practice.  Should we change this?  For example, we could decide to
include a few people who aren't currently acting as a maintainer, but
are fairly prolific contirbutors / reviewers.  I do *include* such
people for consideration in our ballots, but they tend not to be
chosen by the program committee.  Should we change our criteria to
explicitly include a few such folks?

Cheers,

					- Ted

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Lorenzo Stoakes (ARM)]

On Fri, Aug 07, 2026 at 10:27:27AM -0700, Linus Torvalds wrote:
> The maintainer summit being a pretty constant "in-group" is
> fundamental, but it still feels a bit sad and wrong to me.

It feels less like a naturally emerging in-group and more like a clique,
and I've heard the same view expressed to me by a good few other
maintainers.

Its exclusivity is pretty well signalled ([0]):

	"The Linux Kernel Maintainer Summit brings together the world’s
	leading core kernel developers to discuss the state of the existing
	kernel and plan the next development cycle. This is an invite-only
	event."

The procedure for selecting attendees is rather vague ([1]):

	"Linus has generated a list of people for the program committee to
	consider. People who suggest topics that should be discussed at the
	Maintainers Summit will also be added to the list for
	consideration. ... Late submissions will be considered, but people
	submit submissions before September 10th will be considered for
	receiving an invite."

Though seemed to change (maybe?) for 2026 ([2]):

	"The attendees are jointly selected by Linus Torvlads (who has
	provided us with a roughly a dozen maintainers that he would like
	to attend), and the program committee, who choose from maintainers
	and developers who have been the most active in the past year.
	... Anybody proposing a topic before July 24th will be added to the
	list of potential attendees selected by the program committee ... "

All of this seems to tie topic submission with attendance.

It's a little unclear too whether somebody submitting a topic is also
proposing to present it at the session or not. It's somewhat implied but it
doesn't seem to be the case in practice.

For instance, I made a submission last year (I was nagged to by somebody :)
but I had no expectation of being invited as I did not (nor do not)
consider myself anywhere near elite or established enough to fulfil the
criteria above.

I was however slightly disappointed that a session was run on essentially
the same topic I submitted and whose summary ([3], read out at the start)
was posted in the same thread.

The session was run by Sasha who hadn't submitted a topic that year (Jiri
had also made a submission related to LLMs but more specifically about
kernel patch attribution, though he did attend).

That experience overall made it seem very vague as to how topic selection,
who runs the session and attendance actually works.

So at the very least some clarity is needed.

Ted's data from elsewhere in this thread is also rather misleading I feel:

  # Summits
  Attended   #      %
  ------------------------
  4          9    18.37%
  3          8    16.33%
  2         10    20.41%
  1         22    44.90%

It's dealing in people but not seats - i.e. actual conference attendances.

Consider:

  # Summits
  Attended   #      %
  ------------------------
  4         27    55.10%
  1         22    44.90%

It'd _still_ suggest that there was a healthy 44.9% of new faces, even
though this would mean that 83% of every conference was the exact same
people :)

What's missing is factoring in the # summits attended.

So by Ted's data there were 102 seats over the 4 years (9 * 4 + 8 * 3 + 10
* 2 + 22 * 1).

Taking that into account the numbers look very different:

  # Summits
  Attended   #    Seats occupied   %    Cuml %
  --------------------------------------------
  4          9          36       35.3     35.3
  3          8          24       23.5     58.8
  2         10          20       19.6     78.4
  1         22          22       21.6    100.0

That puts the number of seats filled by one-time attendees at any
conference at 21.6%, not 44.9%.

It means that 78.4% of the seats at any given summit on average are filled
by repeat attendees, with 58.8% on average filled by people who attended 3
or 4 conferences.

Which entirely backs up that it is a clique - the same majority in every
room.

Also, the committee who select attendees (through unclear criteria) are
themselves drawn from that same core of repeat attendees.

I mean I don't know, maybe it's necessary to run it as a tight ship of
trusted people, but I think we should at least be more clear about that.

However I wonder whether we should look at an alternative approach like
those with M: entries in MAINTAINERS voting on topics, or something
similar.

Not sure if that's a good or terrible idea but it's something :)

--
Cheers, Lorenzo

[0]:https://events.linuxfoundation.org/linux-kernel-maintainer-summit/
[1]:https://lore.kernel.org/all/20250805144357.GA762104@mit.edu/
[2]:https://lore.kernel.org/all/alW3eJ9x6iJ8Juhi@mit.edu/
[3]:https://lore.kernel.org/all/aTYmE53i3FJ_lJH2@laps/

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Lorenzo Stoakes (ARM)]

+cc Ted, Sasha, Jiri

(Sorry, hit send before adding cc's...!)

On Sun, Aug 09, 2026 at 07:39:43PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Fri, Aug 07, 2026 at 10:27:27AM -0700, Linus Torvalds wrote:
> > The maintainer summit being a pretty constant "in-group" is
> > fundamental, but it still feels a bit sad and wrong to me.
>
> It feels less like a naturally emerging in-group and more like a clique,
> and I've heard the same view expressed to me by a good few other
> maintainers.
>
> Its exclusivity is pretty well signalled ([0]):
>
> 	"The Linux Kernel Maintainer Summit brings together the world’s
> 	leading core kernel developers to discuss the state of the existing
> 	kernel and plan the next development cycle. This is an invite-only
> 	event."
>
> The procedure for selecting attendees is rather vague ([1]):
>
> 	"Linus has generated a list of people for the program committee to
> 	consider. People who suggest topics that should be discussed at the
> 	Maintainers Summit will also be added to the list for
> 	consideration. ... Late submissions will be considered, but people
> 	submit submissions before September 10th will be considered for
> 	receiving an invite."
>
> Though seemed to change (maybe?) for 2026 ([2]):
>
> 	"The attendees are jointly selected by Linus Torvlads (who has
> 	provided us with a roughly a dozen maintainers that he would like
> 	to attend), and the program committee, who choose from maintainers
> 	and developers who have been the most active in the past year.
> 	... Anybody proposing a topic before July 24th will be added to the
> 	list of potential attendees selected by the program committee ... "
>
> All of this seems to tie topic submission with attendance.
>
> It's a little unclear too whether somebody submitting a topic is also
> proposing to present it at the session or not. It's somewhat implied but it
> doesn't seem to be the case in practice.
>
> For instance, I made a submission last year (I was nagged to by somebody :)
> but I had no expectation of being invited as I did not (nor do not)
> consider myself anywhere near elite or established enough to fulfil the
> criteria above.
>
> I was however slightly disappointed that a session was run on essentially
> the same topic I submitted and whose summary ([3], read out at the start)
> was posted in the same thread.
>
> The session was run by Sasha who hadn't submitted a topic that year (Jiri
> had also made a submission related to LLMs but more specifically about
> kernel patch attribution, though he did attend).
>
> That experience overall made it seem very vague as to how topic selection,
> who runs the session and attendance actually works.
>
> So at the very least some clarity is needed.
>
> Ted's data from elsewhere in this thread is also rather misleading I feel:
>
>   # Summits
>   Attended   #      %
>   ------------------------
>   4          9    18.37%
>   3          8    16.33%
>   2         10    20.41%
>   1         22    44.90%
>
> It's dealing in people but not seats - i.e. actual conference attendances.
>
> Consider:
>
>   # Summits
>   Attended   #      %
>   ------------------------
>   4         27    55.10%
>   1         22    44.90%
>
> It'd _still_ suggest that there was a healthy 44.9% of new faces, even
> though this would mean that 83% of every conference was the exact same
> people :)
>
> What's missing is factoring in the # summits attended.
>
> So by Ted's data there were 102 seats over the 4 years (9 * 4 + 8 * 3 + 10
> * 2 + 22 * 1).
>
> Taking that into account the numbers look very different:
>
>   # Summits
>   Attended   #    Seats occupied   %    Cuml %
>   --------------------------------------------
>   4          9          36       35.3     35.3
>   3          8          24       23.5     58.8
>   2         10          20       19.6     78.4
>   1         22          22       21.6    100.0
>
> That puts the number of seats filled by one-time attendees at any
> conference at 21.6%, not 44.9%.
>
> It means that 78.4% of the seats at any given summit on average are filled
> by repeat attendees, with 58.8% on average filled by people who attended 3
> or 4 conferences.
>
> Which entirely backs up that it is a clique - the same majority in every
> room.
>
> Also, the committee who select attendees (through unclear criteria) are
> themselves drawn from that same core of repeat attendees.
>
> I mean I don't know, maybe it's necessary to run it as a tight ship of
> trusted people, but I think we should at least be more clear about that.
>
> However I wonder whether we should look at an alternative approach like
> those with M: entries in MAINTAINERS voting on topics, or something
> similar.
>
> Not sure if that's a good or terrible idea but it's something :)
>
> --
> Cheers, Lorenzo
>
> [0]:https://events.linuxfoundation.org/linux-kernel-maintainer-summit/
> [1]:https://lore.kernel.org/all/20250805144357.GA762104@mit.edu/
> [2]:https://lore.kernel.org/all/alW3eJ9x6iJ8Juhi@mit.edu/
> [3]:https://lore.kernel.org/all/aTYmE53i3FJ_lJH2@laps/

--
Cheers, Lorenzo

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Randy Dunlap]

On 8/8/26 6:51 PM, Theodore Tso wrote:
> As another thought, when we had 100+ people attending the Kernel
> Summit, that we would make a *point* of inviting people who had never
> attended Kernel Summits before, so we would get new blood attending
> the Summit.  After we significantly reduced the the size of the
> Maintainers Summit to 30, we've stopped doing this as a deliberate
> practice.  Should we change this?  For example, we could decide to
> include a few people who aren't currently acting as a maintainer, but
> are fairly prolific contirbutors / reviewers.  I do *include* such

I think this is a very good idea and would like to see this change.

(and I'm not looking for an invitation :)

> people for consideration in our ballots, but they tend not to be
> chosen by the program committee.  Should we change our criteria to
> explicitly include a few such folks?

-- 
~Randy

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Jonathan Corbet]

"Theodore Tso" <tytso@mit.edu> writes:

> As another thought, when we had 100+ people attending the Kernel
> Summit, that we would make a *point* of inviting people who had never
> attended Kernel Summits before, so we would get new blood attending
> the Summit.  After we significantly reduced the the size of the
> Maintainers Summit to 30, we've stopped doing this as a deliberate
> practice.  Should we change this?

FWIW, in my role in the program committee, I have always tried to think
about who we should bring in that hasn't been there before - with a
certain amount of success, I hope.

We could perhaps do better, maybe with a rule that N% of the seats
should be filled by first-time attendees.  But we do also have to be
sure that the right people are in the room handle the topics under
consideration, and that will inevitably include a number of old-timers
who have been there before.

jon

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Steven Rostedt]

On Sun, 09 Aug 2026 13:04:33 -0600
Jonathan Corbet <corbet@lwn.net> wrote:

> We could perhaps do better, maybe with a rule that N% of the seats
> should be filled by first-time attendees.  But we do also have to be
> sure that the right people are in the room handle the topics under
> consideration, and that will inevitably include a number of old-timers
> who have been there before.

The thing is, we need people there that are responsible for the actions
decided at the conference. Getting new folks that do not have a stake in
the decisions is not going to be helpful. This is one reason the same
people are there all the time. They are usually the maintainers that may be
most affected by the decisions made.

For instance, last year the session about best practices with linux-next[1],
DRM was brought up as one of the subsystems that did a lot of rebases.
Without Dave Airlie there to explain why he does it the way he does, there
may have been decisions made that could have negatively impacted the DRM
subsytem.

What is the goal of Maintainers Summit? Is it to fix issues that we are
currently having with the process? If so, it is best to get the people
there that are having the issues and those that can help solve them. It
should not be a vanity affair where people can have bragging rights for
attending.

This should not hinder new people from being invited. As the kernel
changes, new people start to have more stake in the kernel. People like
Miguel and I would even argue for Lorenzo ;-)

-- Steve


[1] https://lwn.net/Articles/1050027/

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Liam R. Howlett]

On 9 August 2026 15:04:33 GMT-04:00, Jonathan Corbet <corbet@lwn.net> wrote:
>"Theodore Tso" <tytso@mit.edu> writes:
>
>> As another thought, when we had 100+ people attending the Kernel
>> Summit, that we would make a *point* of inviting people who had never
>> attended Kernel Summits before, so we would get new blood attending
>> the Summit.  After we significantly reduced the the size of the
>> Maintainers Summit to 30, we've stopped doing this as a deliberate
>> practice.  Should we change this?
>
>FWIW, in my role in the program committee, I have always tried to think
>about who we should bring in that hasn't been there before - with a
>certain amount of success, I hope.
>
>We could perhaps do better, maybe with a rule that N% of the seats
>should be filled by first-time attendees.  But we do also have to be
>sure that the right people are in the room handle the topics under
>consideration, and that will inevitably include a number of old-timers
>who have been there before.
>

As one of the maintainers that has not attended the MS, I cannot fully understand all the issues faced by the group.

But I, like many, joined the kernel community to be part of something bigger than ourselves alone.  The decisions made are not financially motivated, and that alone is worth praise.

Considering the size of the community, I would hope that the people in the room have become more representative of thier subsystem or subgroup than just voicing what they believe is the right path alone.  If that's not the case then I can see why the decision is upsetting; the process is disregarding voices in favour of a known quantity.

I do find that the selection for the group does fall on the usual suspects, and I wonder if introducing some new people could help bring in new views.  

Cycling a percent of new people through will probably not fix this.  You will have 100 first dates to find someone that fits, and potentially 99 other displeased contributors.  That is, it is extremely unlikely the new attendee will get the traction with the regulars and walk away disheartening, offended, or simply as a fly on the wall afraid to say anything.  One could draw parallels with new patch contributors.

We do have more than enough people around in each core area with their views of what's going on and how things should be handled  - which actually sounds like it could be a strength over a source of guilt.

We could have a reserved number of seats dedicated for specific subject that are temporary seats that would be used for a specific topic.  As a specific topic expert or interested party, they would be less likely to stay quiet or be disregarded as not knowing the workings of a specific policy.

This brings to mind something else which I've been think for some time, we should have delegates when someone cannot make it in person.  Not as a replacement, but as someone that can speak up when things are relevant to their particular expertise - and potentially to help the succession planning of that subsystem.

Maybe we expand the group to two people per subsystem/area to better represent the diverse ideas that exist in the group.

Alternatively (or maybe as an addition) we could have pre-MS within each subsystem or related subsystems and a feedback loop after MS.  The idea here is to at least have some voices heard by the maintainer going to the summit for each group.  For example at LFS, we could have topics for the MS to discuss with Andrew before he attends LPC.  We sort of do this already but a formal process across all subsystems should exist.

Thanks,
Liam

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Dave Airlie]

On Mon, 10 Aug 2026 at 04:41, Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
>
> On Fri, Aug 07, 2026 at 10:27:27AM -0700, Linus Torvalds wrote:
> > The maintainer summit being a pretty constant "in-group" is
> > fundamental, but it still feels a bit sad and wrong to me.
>
> It feels less like a naturally emerging in-group and more like a clique,
> and I've heard the same view expressed to me by a good few other
> maintainers.

Not to be pedantic, but these are the same thing. How can you make any
reasonsable interpretation of clique vs emerging in-group in a group
of 30-100 people.

I'm one of those who attended every maintainer summit since inception,
including the one at 2am my time during COVID. I'm quite vocal in the
room on behalf of my subsystem and myself, but at no point have I ever
felt part of a clique or in-group at all.

I think people really have a misconception about what goes on at the
maintainer summit, the best explanation I've been given was that it is
Linus's staff meeting. The people that Linus works with closest, get
invited to talk to Linus and help him figure out where the overall
ship is going and where things are going wrong.

There is usually 0 useful technical content, and we've certainly never
taken a vote on anything. Like I get some parts of mm might feel
controversial and you want to think that talking in that group might
be useful, but it's not.

I generally go on behalf of drm, because I'm the person who interacts
with Linus the most, and I'm weary of wasting anyone else times on
going because they feel there is some brilliant clique or in-group
they are not part of.

> For instance, I made a submission last year (I was nagged to by somebody :)
> but I had no expectation of being invited as I did not (nor do not)
> consider myself anywhere near elite or established enough to fulfil the
> criteria above.

Your language choice already makes it feel like you see it as some
elite or special group. It's a bunch of technical project managers
talking about the processes of producing the kernel. If a talk about
the technical content of the kernel sneaks in it's very rare and also
usually not of interest to half the room.

> I mean I don't know, maybe it's necessary to run it as a tight ship of
> trusted people, but I think we should at least be more clear about that.
>
> However I wonder whether we should look at an alternative approach like
> those with M: entries in MAINTAINERS voting on topics, or something
> similar.

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.

Dave.

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Theodore Tso]

On Sun, Aug 09, 2026 at 05:56:45PM -0500, Liam R. Howlett wrote:
> 
> We could have a reserved number of seats dedicated for specific
> subject that are temporary seats that would be used for a specific
> topic.  As a specific topic expert or interested party, they would
> be less likely to stay quiet or be disregarded as not knowing the
> workings of a specific policy.

One of the reasons why we discuss maintainers summit topics in advance
is partially to create the agenda, but to also be aware who some of
the interested parties will be.  And the program committee *does* take
that into account.

The other reason why the discussions on the ksummit list are so useful
is that it *is* a pre-MS discussion.  Everyone gets to hear the voices
who feel strongly about a particular topic --- for example, such as
the AI/LLM discussion.  The voices and ideas that are presented in the
mailing list is absolutely something that influences the discussion
that happens in the room.

> This brings to mind something else which I've been think for some
> time, we should have delegates when someone cannot make it in
> person.  Not as a replacement, but as someone that can speak up when
> things are relevant to their particular expertise - and potentially
> to help the succession planning of that subsystem.

As far as succession planning of a subsystem, I'd argue that MS isn't
the best place.  For example, at this year's LSF/MM/BPF, the
discussion over succession planning of the mm subsystem took place
there.  There was also a discussion about how the FUSE developers
would organize themselves that took place at LSF/MM.  Those
discussions would not be of interest to most the attendees of the
Maintainers Summit, since most of those decisions are quite
decentralized, where a networking or BPF maintainer isn't going to be
dictating succession planning of MM subsystem (for example).  This is
why other venues, such LSF/MM. KVM Forum, Networking Summit, Plumbers
Miniconfs or BOF's, are probably suitable for those sorts of
discussions.

Cheers,

					- Ted

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Liam R. Howlett]

On 9 August 2026 21:26:53 GMT-04:00, Theodore Tso <tytso@mit.edu> wrote:
>On Sun, Aug 09, 2026 at 05:56:45PM -0500, Liam R. Howlett wrote:
>> 
>> We could have a reserved number of seats dedicated for specific
>> subject that are temporary seats that would be used for a specific
>> topic.  As a specific topic expert or interested party, they would
>> be less likely to stay quiet or be disregarded as not knowing the
>> workings of a specific policy.
>
>One of the reasons why we discuss maintainers summit topics in advance
>is partially to create the agenda, but to also be aware who some of
>the interested parties will be.  And the program committee *does* take
>that into account.
>
>The other reason why the discussions on the ksummit list are so useful
>is that it *is* a pre-MS discussion.  Everyone gets to hear the voices
>who feel strongly about a particular topic --- for example, such as
>the AI/LLM discussion.  The voices and ideas that are presented in the
>mailing list is absolutely something that influences the discussion
>that happens in the room.

But not *who* is in the room for those topics?  I'm suggesting that you could select someone outside the core group to provide input for the topic.  It appears to everyone that the core group is constantly selected and I am trying to suggest ways to help expand the views.  I am beginning to think no new ideas are wanted, tbh.

>
>> This brings to mind something else which I've been think for some
>> time, we should have delegates when someone cannot make it in
>> person.  Not as a replacement, but as someone that can speak up when
>> things are relevant to their particular expertise - and potentially
>> to help the succession planning of that subsystem.
>
>As far as succession planning of a subsystem, I'd argue that MS isn't
>the best place.  For example, at this year's LSF/MM/BPF, the
>discussion over succession planning of the mm subsystem took place
>there.  

I have no idea how you read what I typed and came up with this response.

Let me try again.

The memory management (MM) subsystem will have a new lead maintainer within the near future that will be representing us at MS (if we have a seat at the table at all).  What happened differently last year and this year in the planning committee to account for this upcoming change and how it will impact MS?

Liam

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Lorenzo Stoakes (ARM)]

On Mon, Aug 10, 2026 at 08:10:21AM +1000, Dave Airlie wrote:
...
> I think people really have a misconception about what goes on at the
> maintainer summit, the best explanation I've been given was that it is
> Linus's staff meeting. The people that Linus works with closest, get
> invited to talk to Linus and help him figure out where the overall
> ship is going and where things are going wrong.
...
> Your language choice already makes it feel like you see it as some
> elite or special group. It's a bunch of technical project managers
> talking about the processes of producing the kernel. If a talk about
> the technical content of the kernel sneaks in it's very rare and also
> usually not of interest to half the room.
...
>
> > I mean I don't know, maybe it's necessary to run it as a tight ship of
> > trusted people, but I think we should at least be more clear about that.

I mean this is kinda my point.

It is being advertised as X but is actually Y. So say it's Y.

That's not what Ted's posts or the write ups or generally any comms about the MS
say it is.

The CFP-ish bit is probably pretty redundant too on this basis?

> >
> > However I wonder whether we should look at an alternative approach like
> > those with M: entries in MAINTAINERS voting on topics, or something
> > similar.
>
> 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 ;)

>
> Dave.

--
Cheers, Lorenzo

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Geert Uytterhoeven]

On Mon, 10 Aug 2026 at 00:10, Dave Airlie <airlied@gmail.com> wrote:
> I think people really have a misconception about what goes on at the
> maintainer summit, the best explanation I've been given was that it is
> Linus's staff meeting. The people that Linus works with closest, get
> invited to talk to Linus and help him figure out where the overall
> ship is going and where things are going wrong.

That was also my impression.

On Sat, 8 Aug 2026 at 01:20, Theodore Tso <tytso@mit.edu> wrote:
> Today, the Maintainer Summit is basically a half-day event, with
> around 30 people (plus any sponsored attendees), and is only focused
> on process questions, with the technical discussions taking place at

Forgive my ignorance, how do the sponsored attendees fit into this
picture?

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

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Lorenzo Stoakes (ARM)]

+cc David as reference below.

On Sun, Aug 09, 2026 at 09:26:53PM -0400, Theodore Tso wrote:
> On Sun, Aug 09, 2026 at 05:56:45PM -0500, Liam R. Howlett wrote:
> >
> > We could have a reserved number of seats dedicated for specific
> > subject that are temporary seats that would be used for a specific
> > topic.  As a specific topic expert or interested party, they would
> > be less likely to stay quiet or be disregarded as not knowing the
> > workings of a specific policy.
>
> One of the reasons why we discuss maintainers summit topics in advance
> is partially to create the agenda, but to also be aware who some of
> the interested parties will be.  And the program committee *does* take
> that into account.
>
> The other reason why the discussions on the ksummit list are so useful
> is that it *is* a pre-MS discussion.  Everyone gets to hear the voices
> who feel strongly about a particular topic --- for example, such as
> the AI/LLM discussion.  The voices and ideas that are presented in the
> mailing list is absolutely something that influences the discussion
> that happens in the room.

Your emails are really unclear.

They say this:

	The attendees are jointly selected by Linus Torvlads (who has provided
	us with a roughly a dozen maintainers that he would like to attend),
	and the program committee, who choose from maintainers and developers
	who have been the most active in the past year.

(Though I question whether 'most active' is a good metric or one that's
actually being used).

OK cool - as David Airlie says - it's Linus's staff meeting and people he
most interacts with are invited, fine.

But then you say this:

	Anybody proposing a topic before July 24th will be added to the list
	of potential attendees selected by the program committee; other
	potential nominees can be proposed (as a self-nomination or by others)
	by sending a note to the ksumimt list saying why that person's
	presence would help the discussion.

Which is like a CFP at any other conference implying that topic submission
is tied to attendance.

I think you should make it clear that topic suggestion is entirely separate.

Right now it seems to me to be a bit of a muddle.

--
Cheers, Lorenzo

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Lorenzo Stoakes (ARM)]

+cc 2*David, Liam, Andrew as referenced below

On Sun, Aug 09, 2026 at 05:09:18PM -0400, Steven Rostedt wrote:
> This should not hinder new people from being invited. As the kernel
> changes, new people start to have more stake in the kernel. People like
> Miguel and I would even argue for Lorenzo ;-)

That's very kind of you and Miguel ;)

However I'm nowhere near the caliber of attendee the LF describes and if anybody
from mm should attend it should be David as Liam also suggested :)

In fact as David is taking over (albeit for a transitional period) from Andrew,
it makes sense that he be invited _this_ year in my view.

Linus will soon be interacting with him a lot :) so he also fulfils David
Airlie's description of the MS (which I do think is the accurate one).

--
Cheers, Lorenzo

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Steven Rostedt]

On Mon, 10 Aug 2026 08:26:36 +0100
"Lorenzo Stoakes (ARM)" <ljs@kernel.org> 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. 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.

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.

Dave, feel free to correct me where I'm wrong.

-- Steve

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Steven Rostedt]

On Mon, 10 Aug 2026 09:14:56 +0100
"Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:

> +cc 2*David, Liam, Andrew as referenced below
> 
> On Sun, Aug 09, 2026 at 05:09:18PM -0400, Steven Rostedt wrote:
> > This should not hinder new people from being invited. As the kernel
> > changes, new people start to have more stake in the kernel. People like
> > Miguel and I would even argue for Lorenzo ;-)  
> 
> That's very kind of you and Miguel ;)

Oops, Miguel didn't say that. I worded that wrong. Or at least I didn't add
enough commas:

  "People like Miguel, and I would even argue for, Lorenzo"

As in, People like Miguel and Lorenzo. And I would argue for you.

> 
> However I'm nowhere near the caliber of attendee the LF describes and if anybody
> from mm should attend it should be David as Liam also suggested :)
> 
> In fact as David is taking over (albeit for a transitional period) from Andrew,
> it makes sense that he be invited _this_ year in my view.

It's also about who is able to articulate issues, not just their standing in
the community. You are very vocal and able to bring up things that should
be talked about. If we have someone that is higher up the maintainer
hierarchy, but doesn't speak up, they may not be as useful.

I'm not saying that David or Liam wouldn't speak up. What I am saying is
that it's not the only criteria.

> Linus will soon be interacting with him a lot :) so he also fulfils David
> Airlie's description of the MS (which I do think is the accurate one).

It is partially Linus's "staff meeting", but to me, it's about maintainers
coming together to settle differences about what is happening within the
Linux kernel community. I view Linus as more of the "Judge" who stays
mostly quiet and just listens and then if things do not get settled between
developers, he will speak up. Similarly to what he does on the mailing list.

-- Steve

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[James Bottomley]

On Mon, 2026-08-10 at 09:11 -0400, Steven Rostedt wrote:
> On Mon, 10 Aug 2026 08:26:36 +0100
> "Lorenzo Stoakes (ARM)" <ljs@kernel.org> 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

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[James Bottomley]

On Fri, 2026-08-07 at 19:19 -0400, Theodore Tso wrote:
[...]
> We can split this discussion a couple of different ways.  The first
> is how can we make the Maintainers Summit more valuable.  I do think
> that in the last couple of years, there *have* been a number of quite
> valuable discussions, but it's always worthwhile to consider ways in
> which we can improve the discussion.  So that's on the "benefits"
> side of the equation.

So I think we first need to start with the problem statement.  I think
it's that Linus doesn't go to any other conferences except MS, so for
him to discuss stuff with us in person, or us to discuss things with
him the issue has to be scheduled for MS.  Linus supplies an attendee
list for the former and a selection committee tries to put together the
latter ... is that about right?  For that second half, perhaps we
should talk about *how* we do this.  Mostly we go to our other
conferences and resolve stuff and run it by Linus in email, so no in-
person discussion is needed. However, perhaps we could do more active
gathering of the problems that might benefit from in-person discussion
than waiting for them to turn up on this list (or we could possibly
instruct all the maintainers to keep a curated list they dump here).

The second problem, as I see it is representation and franchise.  Dave
stated, and I agree, that MS isn't a representative decision making
body (no-one votes on stuff).  However, it does get treated as one in
certain circumstances: the conclave.rst document does and we also get
topics that are brought up at MS and then considered blessed for action
without wider discussion (expelling Russian Developers would be a great
example of this).  So we need to fix this dichotomy, either by making
it more representative or by being stricter about insisting on onward
discussion of outcomes.

The third problem is that the attendee list, however it is arrived at,
might not be the best at achieving all around discussion of the actual
scheduled topics because of the 'in-group' problem as Linus puts it. 
We could fix this by quite a few means, as has been discussed: lottery,
rotating invites among existing maintainers, etc.  However, I think the
core problem is that 30 people is too small to achieve this and some
form of expansion is going to have to be done.

Regards,

James

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Steven Rostedt]

On Mon, 10 Aug 2026 09:32:24 -0400
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> > 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?

But they are "weird architectures". That is, basically something that is
not the norm, and needs to work with the main core to come up with
solutions. Heck this is what we had to do to get RT working. 

> 
> >  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.

That's a good question for Dave Airlie. Is it possible to make a general
abstraction with DRM (much like VFS)? It sounded to me that the "weird
architectures" of DRM was the norm not the exception. Perhaps it is more
like what ARM was before Linus told them to get their act together.

> 
> > 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?

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.

Perhaps we can look at the process of these other big subsystems to see how
it could help out DRM. Maybe this would make Dave's job easier?

-- Steve

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Steven Rostedt]

On Mon, 10 Aug 2026 09:54:31 -0400
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> So I think we first need to start with the problem statement.  I think
> it's that Linus doesn't go to any other conferences except MS, so for
> him to discuss stuff with us in person, or us to discuss things with
> him the issue has to be scheduled for MS.

Honestly, I believe if Linus just came to Linux Plumbers and hung out and
talked with the developers there, it would allow him to get a good
representation of the happenings of his kernel.

That may make MS obsolete, and he wouldn't have to stay in a room for half
a day discussion various things that could have been BoFs at Plumbers.

When he sat in on the printk session in Dublin, he listen throughout the
presentation and then gave his opinion about it at the end. I thought that
was way more productive than any MS session we had. It wasn't just a
technical talk. It was about changing how printk worked and how it may
impact people who use it in various ways. Something that affects pretty
much all subsystems.

Plumbers has a much more diverse attendance with respect to things within
the kernel. I know Linus hates conferences but Plumbers is basically what
kernel summit used to be at a much larger scale.

-- Steve

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Theodore Tso]

On Mon, Aug 10, 2026 at 09:08:32AM -0500, Lorenzo Stoakes (ARM) wrote:
> Your emails are really unclear.

Ok, let me trry to clarify.  The current process that we've used for
the last couple of years work like this.

1) I send a message to Linus asking for his set of ~10-12 people that
he definitely would like to attend the Maintainers Summit.  He uses
some scripts that show who he pulls from the most, but it's also
modified by his perception of who might be a good people to attend and
to make sure we have a balance between different subsystems and
constituencies (e.g., architecture maintainers, people who work for
distributions, etc.)  People identified by Linus, plus the program
committee, are on the automatic invite list.  (Roughly half of the 5
person program committee overlap with Linus's list.)

2) We send out the Call for Topics, which among other things states
that (a) anyone who suggests a topic before a cutoff date will get
added to the list of people whom the program committee will consider,
and (b) anyone can nominate others, or self-nominate others.

3) In parallel, I run a set of scripts that look for people who are
the most active in the past year, which includes people who review
commits, test commits, author commits, etc.  My scripts are a bit more
expansive than Linus's (which tend to be much more focused on
identifying the core maintainers).

3) The program committee will take a look at the list composed of
people from (2) and (3), and nominate other people to be considered.
This falls under the "anyone can nominate others" clause in (2b)
above, but I call this out because in practice the program committee
tends to nominate more people than non-program committee member
(including self-nominations).  It is at this point that if we think
someone has something important to contribute for a particular topic,
we might make sure that they are added to the list.

4) Each program committee then assigns a score from 5 (this person
must be there) to 1 (while we're at it, why don't we invite Darl
McBride).  We then average the scores, and for the sake of efficiency,
we'll decide on cut line where everyone above a particular line will
be added to the invite list.  But it's not just a mechnical exercise.
We do try to consider balance, people who might be needed to have a
robust set of discussions, people who haven't attended recently or at
all, etc.  HOWEVER, given that we we are limited to inviting 30
people, our ability to achieev balance or to make sure very single
point of view on a topic is represented is quite limited.

> (Though I question whether 'most active' is a good metric or one that's
> actually being used).

It's a starting point (among others) for creating a list of people for
the program committee to consider.  It's not the most important
criteria by any means.

The bottom line is that it's complicated, and we are trying to balance
many competing goals while keeping the size of the summit small enough
that we can have good discussions.  Can it be changed?  Sure!  I'm
sure that based on the discussion on the list, it will almost
certainly come up at the summit.  I can't guarantee that changes will
be made, since it is very much an over-constrained problem, but it
will be discussed.


It might be helpful if people frame the Maintainer Summit as being no
different than what happens at the subsystem level, except that it is
exclusively focused on process issues.  A wise maintainer will take
the concerns of the subsystem contributors in mind, because you can't
force volunteers to work on your subsystem --- and you don't want them
to quit.  But at the same time, it's not a democracy, and a maintainer
is empowered to make decisions for the good of the subsystem.  The
mailing list discussion is an important part of what a wise maintainer
will take into account, and that's why if you want to make sure an
idea is considered, please make it on the ksummit list.

Cheers,

						- Ted

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Theodore Tso]

On Mon, Aug 10, 2026 at 09:42:12AM -0500, Geert Uytterhoeven wrote:
> On Sat, 8 Aug 2026 at 01:20, Theodore Tso <tytso@mit.edu> wrote:
> > Today, the Maintainer Summit is basically a half-day event, with
> > around 30 people (plus any sponsored attendees), and is only focused
> > on process questions, with the technical discussions taking place at
> 
> Forgive my ignorance, how do the sponsored attendees fit into this
> picture?

Sponsored attendees are part of the "pay to play" aspect of how we try
to get sponsorship dollars.  There can be up to 5 sponsored attendees,
but I don't think we've ever had more than 2 sponsored attendees;
sometimes a sponsor won't even send an attendee even if their
sponsorship level would entitle them to do so.

In practice, it's rare that a sponsored attendee actually speaks up at
the Maintainers Summit, and for last 3 years, we haven't had any
sponsors, so more recently Linux Foundation, not the sponsors have
been paying the cost.

The "Pay to Play" model for invite-only workshops has worked much
better for LSF/MM, because companies are generally much more willing
to pay $$$ to get in front of the upstream developers to get them to
consider some technical proposal.  When we had technical discussions
happening at the Kernel Summit, that was definitely the dynamic.  But
most companies are much less interested in trying to inject proposals
into process discussions.  Especially in recent years, allocating
dollars to pay for more AI data centers seem to be more important than
many things, not just conference sponsorships.  :-)

Cheers,

						- Ted

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]

On Mon, Aug 10, 2026 at 10:24:23AM -0400, Steven Rostedt wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> > 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.

> That's a good question for Dave Airlie. Is it possible to make a general
> abstraction with DRM (much like VFS)? It sounded to me that the "weird
> architectures" of DRM was the norm not the exception. Perhaps it is more
> like what ARM was before Linus told them to get their act together.

I don't think any of that stuff is really what's causing issues with DRM
externally - for -next the issues I see are the constant cherry picking
(which I gather is also an issue for stable), and outside of that the
thing that comes up a lot is that it can be hard to get someone to take
responsibility for actually applying a patch if you're not a DRM person
since the responsibility is more diffuse.  This can lead to issues like:

  https://lore.kernel.org/r/46b86d82-6ff4-458a-ac7e-cbbae214b4e5@I-love.SAKURA.ne.jp

or things where the DRM parts of a cross tree series look like they're
being ignored.

> > 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Lorenzo Stoakes (ARM)]

On Mon, Aug 10, 2026 at 10:56:18AM -0400, Theodore Tso wrote:
> On Mon, Aug 10, 2026 at 09:08:32AM -0500, Lorenzo Stoakes (ARM) wrote:
> > Your emails are really unclear.
>
> Ok, let me trry to clarify.  The current process that we've used for
> the last couple of years work like this.
>
> 1) I send a message to Linus asking for his set of ~10-12 people that
> he definitely would like to attend the Maintainers Summit.  He uses
> some scripts that show who he pulls from the most, but it's also
> modified by his perception of who might be a good people to attend and
> to make sure we have a balance between different subsystems and
> constituencies (e.g., architecture maintainers, people who work for
> distributions, etc.)  People identified by Linus, plus the program
> committee, are on the automatic invite list.  (Roughly half of the 5
> person program committee overlap with Linus's list.)
>
> 2) We send out the Call for Topics, which among other things states
> that (a) anyone who suggests a topic before a cutoff date will get
> added to the list of people whom the program committee will consider,
> and (b) anyone can nominate others, or self-nominate others.
>
> 3) In parallel, I run a set of scripts that look for people who are
> the most active in the past year, which includes people who review
> commits, test commits, author commits, etc.  My scripts are a bit more
> expansive than Linus's (which tend to be much more focused on
> identifying the core maintainers).
>
> 3) The program committee will take a look at the list composed of
> people from (2) and (3), and nominate other people to be considered.
> This falls under the "anyone can nominate others" clause in (2b)
> above, but I call this out because in practice the program committee
> tends to nominate more people than non-program committee member
> (including self-nominations).  It is at this point that if we think
> someone has something important to contribute for a particular topic,
> we might make sure that they are added to the list.
>
> 4) Each program committee then assigns a score from 5 (this person
> must be there) to 1 (while we're at it, why don't we invite Darl
> McBride).  We then average the scores, and for the sake of efficiency,
> we'll decide on cut line where everyone above a particular line will
> be added to the invite list.  But it's not just a mechnical exercise.
> We do try to consider balance, people who might be needed to have a
> robust set of discussions, people who haven't attended recently or at
> all, etc.  HOWEVER, given that we we are limited to inviting 30
> people, our ability to achieev balance or to make sure very single
> point of view on a topic is represented is quite limited.
>
> > (Though I question whether 'most active' is a good metric or one that's
> > actually being used).
>
> It's a starting point (among others) for creating a list of people for
> the program committee to consider.  It's not the most important
> criteria by any means.
>
> The bottom line is that it's complicated, and we are trying to balance
> many competing goals while keeping the size of the summit small enough
> that we can have good discussions.  Can it be changed?  Sure!  I'm
> sure that based on the discussion on the list, it will almost
> certainly come up at the summit.  I can't guarantee that changes will
> be made, since it is very much an over-constrained problem, but it
> will be discussed.
>
>
> It might be helpful if people frame the Maintainer Summit as being no
> different than what happens at the subsystem level, except that it is
> exclusively focused on process issues.  A wise maintainer will take
> the concerns of the subsystem contributors in mind, because you can't
> force volunteers to work on your subsystem --- and you don't want them
> to quit.  But at the same time, it's not a democracy, and a maintainer
> is empowered to make decisions for the good of the subsystem.  The
> mailing list discussion is an important part of what a wise maintainer
> will take into account, and that's why if you want to make sure an
> idea is considered, please make it on the ksummit list.

Thanks, that's all really useful information, and I appreciate you taking
the time to go into detail.

For me the real issue here I think is less how it works and more how it's
perceived to work.

Having insight into the selection criteria and the problems you're trying
to solve is really helpful.

I actually think it'd be really useful to document this somewhere in
Documentation/process/ personally.

But for me again I think there's room for improvement in the Call For
Topics which, at least partly, reads like any other conference CFP and
clearly - that isn't the case.

So I think the simple solution here is to reword the CF[P,T, whatever :P]

The bit I'd change is the topic proposal bit. Something like this:


-	Anybody proposing a topic before July 24th will be added to the list
-	of potential attendees selected by the program committee; other
-	potential nominees can be proposed (as a self-nomination or by others)
+	Potential nominees can be proposed (as a self-nomination or by others)
	by sending a note to the ksumimt list saying why that person's
	presence would help the discussion.

And maybe add something extra to really clarify things:

+	The Maintainers Summit is unlike any other conference in the
+	calendar and as such the primary selection criteria for attendance
+	is upstream engagement.
+
+	Therefore, while topic submissions drive what is discussed at the
+	conference and taken very seriously, they do not guarantee
+	attendance.

Keeping the rest the same.

>
> Cheers,
>
> 						- Ted

--
Cheers, Lorenzo

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Randy Dunlap]

On 8/10/26 8:23 AM, Mark Brown wrote:
> I don't think any of that stuff is really what's causing issues with DRM
> externally - for -next the issues I see are the constant cherry picking
> (which I gather is also an issue for stable), and outside of that the
> thing that comes up a lot is that it can be hard to get someone to take
> responsibility for actually applying a patch if you're not a DRM person
> since the responsibility is more diffuse.  This can lead to issues like:

That's even true for simple kernel-doc patches. :(

> 
>   https://lore.kernel.org/r/46b86d82-6ff4-458a-ac7e-cbbae214b4e5@I-love.SAKURA.ne.jp
> 
> or things where the DRM parts of a cross tree series look like they're
> being ignored.

-- 
~Randy

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Liam R. Howlett]

On 10 August 2026 09:20:03 GMT-04:00, Steven Rostedt <rostedt@goodmis.org> wrote:
>On Mon, 10 Aug 2026 09:14:56 +0100
>"Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
>
>> +cc 2*David, Liam, Andrew as referenced below
>> 
>> On Sun, Aug 09, 2026 at 05:09:18PM -0400, Steven Rostedt wrote:
>> > This should not hinder new people from being invited. As the kernel
>> > changes, new people start to have more stake in the kernel. People like
>> > Miguel and I would even argue for Lorenzo ;-)  
>> 
>> That's very kind of you and Miguel ;)
>
>Oops, Miguel didn't say that. I worded that wrong. Or at least I didn't add
>enough commas:
>
>  "People like Miguel, and I would even argue for, Lorenzo"
>
>As in, People like Miguel and Lorenzo. And I would argue for you.
>
>> 
>> However I'm nowhere near the caliber of attendee the LF describes and if anybody
>> from mm should attend it should be David as Liam also suggested :)
>> 
>> In fact as David is taking over (albeit for a transitional period) from Andrew,
>> it makes sense that he be invited _this_ year in my view.
>
>It's also about who is able to articulate issues, not just their standing in
>the community. You are very vocal and able to bring up things that should
>be talked about. If we have someone that is higher up the maintainer
>hierarchy, but doesn't speak up, they may not be as useful.
>
>I'm not saying that David or Liam wouldn't speak up. What I am saying is
>that it's not the only criteria.

I don't want to be invited.  My only reason for being vocal is to facilitate process improvements.

Thanks,
Liam

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Steven Rostedt]

On Mon, 10 Aug 2026 16:35:48 -0400
"Liam R. Howlett" <liam@infradead.org> wrote:


> I don't want to be invited.  My only reason for being vocal is to facilitate process improvements.

So... if this topic is selected for the MS agenda, you would be a perfect
person to invite ;-)

-- Steve

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Dave Airlie]

On Mon, 10 Aug 2026 at 17:26, Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
>
> On Mon, Aug 10, 2026 at 08:10:21AM +1000, Dave Airlie wrote:
> ...
> > I think people really have a misconception about what goes on at the
> > maintainer summit, the best explanation I've been given was that it is
> > Linus's staff meeting. The people that Linus works with closest, get
> > invited to talk to Linus and help him figure out where the overall
> > ship is going and where things are going wrong.
> ...
> > Your language choice already makes it feel like you see it as some
> > elite or special group. It's a bunch of technical project managers
> > talking about the processes of producing the kernel. If a talk about
> > the technical content of the kernel sneaks in it's very rare and also
> > usually not of interest to half the room.
> ...
> >
> > > I mean I don't know, maybe it's necessary to run it as a tight ship of
> > > trusted people, but I think we should at least be more clear about that.
>
> I mean this is kinda my point.
>
> It is being advertised as X but is actually Y. So say it's Y.
>
> That's not what Ted's posts or the write ups or generally any comms about the MS
> say it is.
>
> The CFP-ish bit is probably pretty redundant too on this basis?

In my opinion, quite a lot of the problems that get raised by the CFP
on this list, often get resolved on this list, which to my mind
suggests we just need to have a better year round maintainers list
that doesn't get consumed by patches or internal subsystem matters.

>
> > >
> > > However I wonder whether we should look at an alternative approach like
> > > those with M: entries in MAINTAINERS voting on topics, or something
> > > similar.
> >
> > 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 ;)

I was more referring to the idea that voting would make any sense in
that forum, I do believe mm should be well represented, but also you
have your own very successful forum, and maybe the mm leadership can
meet at LSFMM and pick 1 or 2 delegates to send to the MS every year,
and they would get auto accepted, this of course wouldn't stop
additional mm folks from attending but at least make sure there are
voices in the room.

Dave.

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Liam R. Howlett]

On 10 August 2026 17:30:48 GMT-04:00, Dave Airlie <airlied@gmail.com> wrote:
>On Mon, 10 Aug 2026 at 17:26, Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
>>
>> On Mon, Aug 10, 2026 at 08:10:21AM +1000, Dave Airlie wrote:
>> ...
>> > I think people really have a misconception about what goes on at the
>> > maintainer summit, the best explanation I've been given was that it is
>> > Linus's staff meeting. The people that Linus works with closest, get
>> > invited to talk to Linus and help him figure out where the overall
>> > ship is going and where things are going wrong.
>> ...
>> > Your language choice already makes it feel like you see it as some
>> > elite or special group. It's a bunch of technical project managers
>> > talking about the processes of producing the kernel. If a talk about
>> > the technical content of the kernel sneaks in it's very rare and also
>> > usually not of interest to half the room.
>> ...
>> >
>> > > I mean I don't know, maybe it's necessary to run it as a tight ship of
>> > > trusted people, but I think we should at least be more clear about that.
>>
>> I mean this is kinda my point.
>>
>> It is being advertised as X but is actually Y. So say it's Y.
>>
>> That's not what Ted's posts or the write ups or generally any comms about the MS
>> say it is.
>>
>> The CFP-ish bit is probably pretty redundant too on this basis?
>
>In my opinion, quite a lot of the problems that get raised by the CFP
>on this list, often get resolved on this list, which to my mind
>suggests we just need to have a better year round maintainers list
>that doesn't get consumed by patches or internal subsystem matters.
>

Reviewed-by.. err.  Yeah, this sound like a decent idea to explore.

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

On Mon, Aug 10, 2026 at 04:23:41PM +0100, Mark Brown wrote:

> I don't think any of that stuff is really what's causing issues with DRM
> externally - for -next the issues I see are the constant cherry picking
> (which I gather is also an issue for stable), and outside of that the

For some numbers on the cherry picking: I'm currently seeing 111 dups in
drm (we also have 6 more in subtrees), out of 1739 total non-merge
commits.  That's about 6% which seems like a lot, and they generate
almost all of the frequent conflicts that DRM generates.  Next on the
list is nfc with 17/35 which is a much larger percentage, and all of the
8 commits in the hyperv-fixes tree are duplicates.

Sometimes trees show up in those numbers transiently due to sending
their patches upstream as email rather than a pull request, that doesn't
seem to be what's going on in the above cases from a quick check.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Theodore Tso]

On Mon, Aug 10, 2026 at 04:35:48PM -0500, Liam R. Howlett wrote:
> 
> I don't want to be invited.  My only reason for being vocal is to
> facilitate process improvements.

Liam, do you have any concrete process improvements that you'd like
propose?

Thanks,

						- Ted

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Dave Airlie]

On Tue, 11 Aug 2026 at 01:52, Randy Dunlap <rdunlap@infradead.org> wrote:
>
>
>
> On 8/10/26 8:23 AM, Mark Brown wrote:
> > I don't think any of that stuff is really what's causing issues with DRM
> > externally - for -next the issues I see are the constant cherry picking
> > (which I gather is also an issue for stable), and outside of that the
> > thing that comes up a lot is that it can be hard to get someone to take
> > responsibility for actually applying a patch if you're not a DRM person
> > since the responsibility is more diffuse.  This can lead to issues like:
>
> That's even true for simple kernel-doc patches. :(
>
> >
> >   https://lore.kernel.org/r/46b86d82-6ff4-458a-ac7e-cbbae214b4e5@I-love.SAKURA.ne.jp
> >
> > or things where the DRM parts of a cross tree series look like they're
> > being ignored.

Is there any tag I can put somewhere that for cross-tree patches that
are just changing and interface, or cleaning up an API change, that we
give you an Ack without getting one, it's really a pointless bit of
review theater if something needs changing.

or can I offer drm-misc commit rights I suppose, but yes we don't have
a good responsible person for acking non-drm patches, and they can
fall down the cracks. But if it's something that can get handled via
another tree, then I'm usually fine with it just going in via that
tree.

Dave.

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Dave Airlie]

> > > 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.

Which means for CI reasons and pipeline reasons, things go into -next
is the default, our -next trees are always open, and get disconnected
from upstream next from rc6->rc1 so not to mess things up.

Then there are people who understand the upstream cycle dealing with
fixes, because they know what goes into rc2 isn't what goes into rc4
isn't what goes into rc7, and that knowledge is hard to disseminate.
Having fixes be a free for all has usually meant me refusing trees in
rc6/rc7 because there are inappropriate patches for that time of the
cycle.

Dave.

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Randy Dunlap]

Hi Dave,

On 8/10/26 8:24 PM, Dave Airlie wrote:
> On Tue, 11 Aug 2026 at 01:52, Randy Dunlap <rdunlap@infradead.org> wrote:
>>
>>
>>
>> On 8/10/26 8:23 AM, Mark Brown wrote:
>>> I don't think any of that stuff is really what's causing issues with DRM
>>> externally - for -next the issues I see are the constant cherry picking
>>> (which I gather is also an issue for stable), and outside of that the
>>> thing that comes up a lot is that it can be hard to get someone to take
>>> responsibility for actually applying a patch if you're not a DRM person
>>> since the responsibility is more diffuse.  This can lead to issues like:
>>
>> That's even true for simple kernel-doc patches. :(
>>
>>>
>>>   https://lore.kernel.org/r/46b86d82-6ff4-458a-ac7e-cbbae214b4e5@I-love.SAKURA.ne.jp
>>>
>>> or things where the DRM parts of a cross tree series look like they're
>>> being ignored.
> 
> Is there any tag I can put somewhere that for cross-tree patches that
> are just changing and interface, or cleaning up an API change, that we
> give you an Ack without getting one, it's really a pointless bit of
> review theater if something needs changing.

I'm not familiar with anything like that.

> or can I offer drm-misc commit rights I suppose, but yes we don't have

No thanks on drm-misc commit rights.
Actually I rather expected these patches to go thru drm-misc instead of you
or Simona handling them.

> a good responsible person for acking non-drm patches, and they can
> fall down the cracks. But if it's something that can get handled via
> another tree, then I'm usually fine with it just going in via that
> tree.

With the understanding above, it might be possible for Jon Corbet or
Andrew Morton to merge these patches.
They can comment if it sounds reasonable to them.

thanks.
-- 
~Randy

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Geert Uytterhoeven]

On Tue, 11 Aug 2026 at 07:29, Randy Dunlap <rdunlap@infradead.org> wrote:
> On 8/10/26 8:24 PM, Dave Airlie wrote:
> > or can I offer drm-misc commit rights I suppose, but yes we don't have
>
> No thanks on drm-misc commit rights.
> Actually I rather expected these patches to go thru drm-misc instead of you
> or Simona handling them.

"Do you have drm-misc commit rights?" is indeed the most common
answer to questions about delayed patches. No, I don't have it,
I don't want it... (Does anyone even know who has? ;-)

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

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Geert Uytterhoeven]

Hi Dave,

On Tue, 11 Aug 2026 at 05:30, Dave Airlie <airlied@gmail.com> wrote:
> > 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.

Doesn't this cause internal (to AMD and Intel) issues, too?
How come we cannot educate contributors at these two large companies,
while we expect other contributors to be aware?
I would hope the people who do the actual commits do know?

> Which means for CI reasons and pipeline reasons, things go into -next
> is the default, our -next trees are always open, and get disconnected
> from upstream next from rc6->rc1 so not to mess things up.

Just merging fixes into next[*], and resolving the conflicts, before
publishing the latter would help a lot.  That would mean the conflicts
would no longer impact every user of your next branch.
[*] This doesn't need to be the real next you will send to Linus
    later. Many maintainers use a conglomerate "for-next" branch that
    is never sent upstream as-is, but its sub-branches are.

FTR, when I create the bi-weekly renesas-drivers releases, drm merge
conflicts are usually the largest conflicts.  Looking at the resolutions
in drm-tip (and linux-next, but broonie is in a less convenient time
zone than sfr was ;-) does help.
Once in a while I think "#@ it, I'll ignore the conflicts and just leave
the conflict markers, my consumers don't use these drivers anyway",
but then the kernel test robot would start complaining to me...

Thanks!

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

Dup commits in NFC trees [Was: Time to call it quits for the maintainer summit?]

[Matthieu Baerts]

Hi Mark,

Moving the discussion to the NFC ML.

On 11/08/2026 00:47, Mark Brown wrote:
> On Mon, Aug 10, 2026 at 04:23:41PM +0100, Mark Brown wrote:
> 
>> I don't think any of that stuff is really what's causing issues with DRM
>> externally - for -next the issues I see are the constant cherry picking
>> (which I gather is also an issue for stable), and outside of that the
> 
> For some numbers on the cherry picking: I'm currently seeing 111 dups in
> drm (we also have 6 more in subtrees), out of 1739 total non-merge
> commits.  That's about 6% which seems like a lot, and they generate
> almost all of the frequent conflicts that DRM generates.  Next on the
> list is nfc with 17/35 which is a much larger percentage, and all of the
> 8 commits in the hyperv-fixes tree are duplicates.
I'm not sure whether you have been aware of this, but NFC has a new
maintainer: David [1]. I see that the new tree is listed in linux-next.

Maybe David doesn't know he is not supposed to cherry-pick commits
between his "for-linus" and "for-next" branches, but he should merge
"for-linux" into "for-next" instead.

[1]
https://lore.kernel.org/20260428-nfc-maintainer-v1-1-4cb9d9e121f3@ixit.cz

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Geert Uytterhoeven]

On Tue, 11 Aug 2026 at 09:12, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, 11 Aug 2026 at 05:30, Dave Airlie <airlied@gmail.com> wrote:
> > > 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.
>
> Doesn't this cause internal (to AMD and Intel) issues, too?
> How come we cannot educate contributors at these two large companies,
> while we expect other contributors to be aware?
> I would hope the people who do the actual commits do know?
>
> > Which means for CI reasons and pipeline reasons, things go into -next
> > is the default, our -next trees are always open, and get disconnected
> > from upstream next from rc6->rc1 so not to mess things up.
>
> Just merging fixes into next[*], and resolving the conflicts, before
> publishing the latter would help a lot.  That would mean the conflicts
> would no longer impact every user of your next branch.

That wouldn't solve the issue for people who care about the actual
commit IDs and not having duplicates, e.g. for stable tacking, and
in Fixes-tags.

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

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Lorenzo Stoakes (ARM)]

On Tue, Aug 11, 2026 at 07:30:48AM +1000, Dave Airlie wrote:
> On Mon, 10 Aug 2026 at 17:26, Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
> >
> > On Mon, Aug 10, 2026 at 08:10:21AM +1000, Dave Airlie wrote:
> > ...
> > > I think people really have a misconception about what goes on at the
> > > maintainer summit, the best explanation I've been given was that it is
> > > Linus's staff meeting. The people that Linus works with closest, get
> > > invited to talk to Linus and help him figure out where the overall
> > > ship is going and where things are going wrong.
> > ...
> > > Your language choice already makes it feel like you see it as some
> > > elite or special group. It's a bunch of technical project managers
> > > talking about the processes of producing the kernel. If a talk about
> > > the technical content of the kernel sneaks in it's very rare and also
> > > usually not of interest to half the room.
> > ...
> > >
> > > > I mean I don't know, maybe it's necessary to run it as a tight ship of
> > > > trusted people, but I think we should at least be more clear about that.
> >
> > I mean this is kinda my point.
> >
> > It is being advertised as X but is actually Y. So say it's Y.
> >
> > That's not what Ted's posts or the write ups or generally any comms about the MS
> > say it is.
> >
> > The CFP-ish bit is probably pretty redundant too on this basis?
>
> In my opinion, quite a lot of the problems that get raised by the CFP
> on this list, often get resolved on this list, which to my mind
> suggests we just need to have a better year round maintainers list
> that doesn't get consumed by patches or internal subsystem matters.

Yeah that's not a bad idea!

Though threads (especially bikesheddable ones) tend to go one of two ways:

1. Some good constructive discussion comes out of it and decisions are made
   (convergent)

2. The conversation turns into the world's biggest talking shop and I want
   to scoop out my eyes with a rusty teaspoon (divergent)

So probably we'd want a way to cut-to-the-chase and say either 'OK cool
let's do X' or STFU :)

>
> >
> > > >
> > > > However I wonder whether we should look at an alternative approach like
> > > > those with M: entries in MAINTAINERS voting on topics, or something
> > > > similar.
> > >
> > > 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 ;)
>
> I was more referring to the idea that voting would make any sense in
> that forum, I do believe mm should be well represented, but also you
> have your own very successful forum, and maybe the mm leadership can
> meet at LSFMM and pick 1 or 2 delegates to send to the MS every year,
> and they would get auto accepted, this of course wouldn't stop
> additional mm folks from attending but at least make sure there are
> voices in the room.

Yeah I see that now, sorry I misunderstood, all I saw were the potatoes ;)
I guess being British I default to always seeing subtext...

And yeah, having 100 equal votes for people who maintain
random-driver-just-because-they-happen-to-work-at-company-X vs. 1 for the
burnout-adjacent maintainer of massive-vital-critical-subsystem-Y doesn't
seem fair either.

Your comment re: this being Linus's staff meeting I think is the best
insight on the thread and very much reflects what I felt it was, and what
I've heard from others about it.

So I think we're pretty much violently agreeing at this stage (well other
than the clique-ness but that's fine).

Anyway the TL;DR way to schtop Lorenzo moaning here (TM) is to edit the CFP
mail a bit to separate attendance from topic submission, something like:

https://lore.kernel.org/ksummit/anntucHhrzF_b4sy@lucifer/

That and ideally adding something in Documentation/process to explain what
the MS is and how it works.

Ted's response there was great and goes into oodles of detail, be good to
save that somewhere to help people (including myself of course) understand
it.

>
> Dave.

--
Cheers, Lorenzo

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Lorenzo Stoakes (ARM)]

On Mon, Aug 10, 2026 at 05:45:29PM -0400, Liam R. Howlett wrote:
> On 10 August 2026 17:30:48 GMT-04:00, Dave Airlie <airlied@gmail.com> wrote:
> >On Mon, 10 Aug 2026 at 17:26, Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
> >>
> >> On Mon, Aug 10, 2026 at 08:10:21AM +1000, Dave Airlie wrote:
> >> ...
> >> > I think people really have a misconception about what goes on at the
> >> > maintainer summit, the best explanation I've been given was that it is
> >> > Linus's staff meeting. The people that Linus works with closest, get
> >> > invited to talk to Linus and help him figure out where the overall
> >> > ship is going and where things are going wrong.
> >> ...
> >> > Your language choice already makes it feel like you see it as some
> >> > elite or special group. It's a bunch of technical project managers
> >> > talking about the processes of producing the kernel. If a talk about
> >> > the technical content of the kernel sneaks in it's very rare and also
> >> > usually not of interest to half the room.
> >> ...
> >> >
> >> > > I mean I don't know, maybe it's necessary to run it as a tight ship of
> >> > > trusted people, but I think we should at least be more clear about that.
> >>
> >> I mean this is kinda my point.
> >>
> >> It is being advertised as X but is actually Y. So say it's Y.
> >>
> >> That's not what Ted's posts or the write ups or generally any comms about the MS
> >> say it is.
> >>
> >> The CFP-ish bit is probably pretty redundant too on this basis?
> >
> >In my opinion, quite a lot of the problems that get raised by the CFP
> >on this list, often get resolved on this list, which to my mind
> >suggests we just need to have a better year round maintainers list
> >that doesn't get consumed by patches or internal subsystem matters.
> >
>
> Reviewed-by.. err.  Yeah, this sound like a decent idea to explore.

Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> also ;)

(I finally made an emacs macro my rubber-stam... err reviewing purposes)

--
Cheers, Lorenzo

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Jiri Kosina]

On Tue, 11 Aug 2026, Lorenzo Stoakes (ARM) wrote:

> > In my opinion, quite a lot of the problems that get raised by the CFP
> > on this list, often get resolved on this list, which to my mind
> > suggests we just need to have a better year round maintainers list
> > that doesn't get consumed by patches or internal subsystem matters.
> 
> Yeah that's not a bad idea!

I think that the workflows@ ML is more or less pretty much exactly for 
this purpose ... ?

-- 
Jiri Kosina
SUSE Labs

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Dave Airlie]

On Tue, 11 Aug 2026 at 19:06, Jiri Kosina <jikos@kernel.org> wrote:
>
> On Tue, 11 Aug 2026, Lorenzo Stoakes (ARM) wrote:
>
> > > In my opinion, quite a lot of the problems that get raised by the CFP
> > > on this list, often get resolved on this list, which to my mind
> > > suggests we just need to have a better year round maintainers list
> > > that doesn't get consumed by patches or internal subsystem matters.
> >
> > Yeah that's not a bad idea!
>
> I think that the workflows@ ML is more or less pretty much exactly for
> this purpose ... ?

workflows@ the cause and solution off all kernel problems...

sorry I didn't sleep much last night :-)

Dave.

Re: Dup commits in NFC trees [Was: Time to call it quits for the maintainer summit?]

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

On Tue, Aug 11, 2026 at 10:12:40AM +0200, Matthieu Baerts wrote:
> On 11/08/2026 00:47, Mark Brown wrote:

> > For some numbers on the cherry picking: I'm currently seeing 111 dups in
> > drm (we also have 6 more in subtrees), out of 1739 total non-merge
> > commits.  That's about 6% which seems like a lot, and they generate
> > almost all of the frequent conflicts that DRM generates.  Next on the
> > list is nfc with 17/35 which is a much larger percentage, and all of the
> > 8 commits in the hyperv-fixes tree are duplicates.

> I'm not sure whether you have been aware of this, but NFC has a new
> maintainer: David [1]. I see that the new tree is listed in linux-next.

Yes, and he's the contact for those trees.

> Maybe David doesn't know he is not supposed to cherry-pick commits
> between his "for-linus" and "for-next" branches, but he should merge
> "for-linux" into "for-next" instead.

Or just not merge them, or wait for Linus to merge things and merge
Linus' tags (that means you also get other bugfixes which can help
people with platform support).  TBH I've not looked at what nfc is doing
since it doesn't really cause any problems for me - I can only see one
conflict I've noticed in the tree and that doesn't look like it was the
result of cherry picking.  I only saw the duplication due to generating
a report.  We don't seem to have ended up with any duplication in
mainline either from a quick check.

IOW it's possible whatever's going on is something that actually works
fine and only results in transient duplications.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

On Tue, Aug 11, 2026 at 01:24:20PM +1000, Dave Airlie wrote:
> On Tue, 11 Aug 2026 at 01:52, Randy Dunlap <rdunlap@infradead.org> wrote:

> > > or things where the DRM parts of a cross tree series look like they're
> > > being ignored.

> Is there any tag I can put somewhere that for cross-tree patches that
> are just changing and interface, or cleaning up an API change, that we
> give you an Ack without getting one, it's really a pointless bit of
> review theater if something needs changing.

> or can I offer drm-misc commit rights I suppose, but yes we don't have
> a good responsible person for acking non-drm patches, and they can
> fall down the cracks. But if it's something that can get handled via
> another tree, then I'm usually fine with it just going in via that
> tree.

The cases I remember were DRM adding something that was then built on by
ASoC (this will have been something to do with HDMI audio I guess, can't
specifically remember).  I guess for that case whoever's pushing the DRM
side ought to either commit stuff and send a PR or be more proactive in
saying "this is OK for DRM, you should take it".  The usual pattern
would be that you'd see an ack from the relevant maintainer on the patch
and know it was OK to pick it up.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Steven Rostedt]

On Tue, 11 Aug 2026 11:06:39 +0200 (CEST)
Jiri Kosina <jikos@kernel.org> wrote:

> On Tue, 11 Aug 2026, Lorenzo Stoakes (ARM) wrote:
> 
> > > In my opinion, quite a lot of the problems that get raised by the CFP
> > > on this list, often get resolved on this list, which to my mind
> > > suggests we just need to have a better year round maintainers list
> > > that doesn't get consumed by patches or internal subsystem matters.  
> > 
> > Yeah that's not a bad idea!  
> 
> I think that the workflows@ ML is more or less pretty much exactly for 
> this purpose ... ?
> 

I thought the same thing.

-- Steve

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2847 bytes --]

On Tue, Aug 11, 2026 at 01:29:37PM +1000, Dave Airlie wrote:

> > 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.

> Which means for CI reasons and pipeline reasons, things go into -next
> is the default, our -next trees are always open, and get disconnected
> from upstream next from rc6->rc1 so not to mess things up.

> Then there are people who understand the upstream cycle dealing with
> fixes, because they know what goes into rc2 isn't what goes into rc4
> isn't what goes into rc7, and that knowledge is hard to disseminate.
> Having fixes be a free for all has usually meant me refusing trees in
> rc6/rc7 because there are inappropriate patches for that time of the
> cycle.

Having everything be a complete free for all does sound like a bad idea
but there's a fairly big gap of processes between there and what's done
currently which is probably worth exploring.  Having a more limited set
of people who can apply things to the fixes branches, having a flow for
getting fixes integrated into the branches that CI looks at and so on.

It strains credibility that it's not possible for people to work out
that a commit clearly labeled as a bug or erratum fix might want to be
routed as a fix, and that with such large teams it's not possible to
arrange for anyone who might be able to confirm this to take a look and
apply to the right place in a reasonably prompt fashion.  Some things it
might be less obvious and some cherry picking might be a sensible way of
dealing with those after the fact but there's a lot of cases where
that's clearly not the case.

Possibly just always merge the fixes branch into the development branch
immediately (or after going through a pile of fixes), it'd result in a
large number of merge commits which would annoy Linus but perhaps he's
not reading the DRM pull requests in enormous detail anyway?

Even just labelling the cherry picks as cherry picks of the original
would be an improvement, right now the cherry picks are completely
silent which really doesn't help anything.  IIRC the stable people have
mentioned that that's one of the things that causes trouble for them.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Dup commits in NFC trees [Was: Time to call it quits for the maintainer summit?]

[David Heidelberg]

On 11/08/2026 15:17, Mark Brown wrote:
> On Tue, Aug 11, 2026 at 10:12:40AM +0200, Matthieu Baerts wrote:
>> On 11/08/2026 00:47, Mark Brown wrote:
> 
>>> For some numbers on the cherry picking: I'm currently seeing 111 dups in
>>> drm (we also have 6 more in subtrees), out of 1739 total non-merge
>>> commits.  That's about 6% which seems like a lot, and they generate
>>> almost all of the frequent conflicts that DRM generates.  Next on the
>>> list is nfc with 17/35 which is a much larger percentage, and all of the
>>> 8 commits in the hyperv-fixes tree are duplicates.
> 
>> I'm not sure whether you have been aware of this, but NFC has a new
>> maintainer: David [1]. I see that the new tree is listed in linux-next.
> 
> Yes, and he's the contact for those trees.
> 
>> Maybe David doesn't know he is not supposed to cherry-pick commits
>> between his "for-linus" and "for-next" branches, but he should merge
>> "for-linux" into "for-next" instead.
> 
> Or just not merge them, or wait for Linus to merge things and merge
> Linus' tags (that means you also get other bugfixes which can help
> people with platform support).  TBH I've not looked at what nfc is doing
> since it doesn't really cause any problems for me - I can only see one
> conflict I've noticed in the tree and that doesn't look like it was the
> result of cherry picking.  I only saw the duplication due to generating
> a report.  We don't seem to have ended up with any duplication in
> mainline either from a quick check.
> 
> IOW it's possible whatever's going on is something that actually works
> fine and only results in transient duplications.

Hello Matthieu and Mark.

Sorry bout that, the nfc-next and nfc-linus will not going to have any 
duplication in future (at least intended duplication).

David

-- 
David Heidelberg

Re: Dup commits in NFC trees [Was: Time to call it quits for the maintainer summit?]

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

On Tue, Aug 11, 2026 at 06:39:33PM +0200, David Heidelberg wrote:
> On 11/08/2026 15:17, Mark Brown wrote:

> > IOW it's possible whatever's going on is something that actually works
> > fine and only results in transient duplications.

> Sorry bout that, the nfc-next and nfc-linus will not going to have any
> duplication in future (at least intended duplication).

Great, thanks - like I say it's not actually been a problem as far as
I've seen, it just came up because the tooling surfaced them and I
mentioned that as part of a discussion of other trees where there are
actually issues.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Rodrigo Vivi]

On Tue, Aug 11, 2026 at 09:12:24AM +0200, Geert Uytterhoeven wrote:
> Hi Dave,
> 
> On Tue, 11 Aug 2026 at 05:30, Dave Airlie <airlied@gmail.com> wrote:
> > > 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.
> 
> Doesn't this cause internal (to AMD and Intel) issues, too?
> How come we cannot educate contributors at these two large companies,
> while we expect other contributors to be aware?
> I would hope the people who do the actual commits do know?

We currently have 52 devs with commit rights in drm-intel and 47 devs
with commit rights on drm-xe (I'm sorry, but I didn't check the union).

But honestly, I don't believe this is the key argument anyway. The key
argument for the drm-intel flow is the CI, pipeline (like Dave wrote
below) and also for historical reasons. When we didn't have this clear
separation with this quarantine weeks (-rc6->-rc1) many last minute
regressions were introduced causing hic-ups on the -rc1 flow for Linus.

Probably worse in our case because our regression makes the screen to
not appear... I don't know.

But well, let's say we keep the quarantine and go with the -fixes and
-next branches without the direct cherry-pick, but the commiters deciding
for witch branch they apply the patches. (Similar to drm-misc flow).
I still see some potential risk scenarios and not a clear benefit:

1. Increase the risk of hic-ups in other fronts. For instance: patches
that should had been merged to -fixes only going to next and forgotten
to be ported to the previous version. And patches that should be new
features due to the risk of regression, added to the previous version.

But here one could argue that in a distributed commit rights flow, this
is exactly why maintainers role is more critical, tto ensure we are not
missing anything and that the patches are moved to the right place.
Fair enough, but this makes our hashes more likely to change. We try
to keep the non-rebasing tree to avoid disruptions in OSVs and many
other teams that are consuming our trees.

2. The conflicts would happen anyway. I still see a lot of conflicts
in the drm-misc flow.

3. Harder to manage the conflicts. Our cherry-pick flow brings some very
obvious conflict resolution to the table. If you are in a newer kernel
you likely only need to go with it is already in our -next branches,
if you are in the current -rc based you likely need to go with what
it ported to -fixes. It really is not something complicated to solve.
But if you go with a flow that the patches don't have the same baseline
like we have the -next and our -tip, then you get harder conflicts to
solve and likely to make more mistakes.

> 
> > Which means for CI reasons and pipeline reasons, things go into -next
> > is the default, our -next trees are always open, and get disconnected
> > from upstream next from rc6->rc1 so not to mess things up.
> 
> Just merging fixes into next[*], and resolving the conflicts, before
> publishing the latter would help a lot.  That would mean the conflicts
> would no longer impact every user of your next branch.
> [*] This doesn't need to be the real next you will send to Linus
>     later. Many maintainers use a conglomerate "for-next" branch that
>     is never sent upstream as-is, but its sub-branches are.

Well, I was going to tell about the drm-tip, but that you already know.
And yes, we cannot have that for-next because it contains topic branches
we really don't want to send up.

Dave, Sima, Jani, perhaps we could instrument dim to create a drm-for-next
that is the merge of all of our relevant branches excluding the topic
branches?

Thanks,
Rodrigo.

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 4116 bytes --]

On Tue, Aug 11, 2026 at 03:54:38PM -0400, Rodrigo Vivi wrote:

> 1. Increase the risk of hic-ups in other fronts. For instance: patches
> that should had been merged to -fixes only going to next and forgotten
> to be ported to the previous version. And patches that should be new
> features due to the risk of regression, added to the previous version.

> But here one could argue that in a distributed commit rights flow, this
> is exactly why maintainers role is more critical, tto ensure we are not
> missing anything and that the patches are moved to the right place.
> Fair enough, but this makes our hashes more likely to change. We try
> to keep the non-rebasing tree to avoid disruptions in OSVs and many
> other teams that are consuming our trees.

I don't think cherry picking if something gets misdirected would be the
end of the world, it's more the fact that you're both doing it as the
normal and default thing and never marking the cherry picks as such that
causes issues.

> 2. The conflicts would happen anyway. I still see a lot of conflicts
> in the drm-misc flow.

> 3. Harder to manage the conflicts. Our cherry-pick flow brings some very
> obvious conflict resolution to the table. If you are in a newer kernel
> you likely only need to go with it is already in our -next branches,
> if you are in the current -rc based you likely need to go with what
> it ported to -fixes. It really is not something complicated to solve.
> But if you go with a flow that the patches don't have the same baseline
> like we have the -next and our -tip, then you get harder conflicts to
> solve and likely to make more mistakes.

The conflicts that I'm seeing from drm are I would say the hardest to
follow, certainly by far the hardest to follow that I see on such a
frequent and routine basis.  They are often huge because of the lack of
shared history between the two branches, there's often enormous sets of
changes on both sides (not helped by all the unadvertised duplication
making the divergent histories bigger) and there's no structure or
explanation for what's going on.  It's all a huge mess, and as a result
it's the area where I make most mistakes and end up having to do time
consuming stuff like repeat builds and merges.

You do sometimes see more complicated things, I do occasionally end up
doing things like just hold a change at an old version and ask for help,
but it's more like once every couple of releases rather than several
times a week.  However with those more complicated cases understanding
what the conflict is tends to be a lot simpler, you can generally see
the two sets of changes and what they're trying to accomplish quite
easily, and the complexity comes from colliding semantic changes in an
unfamiliar area of code.  The fact that with these cases the developers
concerned are usually surprised to learn of the conflict does help a lot
too.

I think from a -next point of view the smallest change that would help
would be if the -next branches you were publishing had all your -fixes
branches and Linus' tree already merged up up, that way any conflicts
that do come up would be actual conflicts with other things rather than
just the rountine conflict spam that should just have been a merge
instead of a cherry pick in the first place.  I believe that this is
what happens before the drm changes get sent to Linus.  That wouldn't
help the stable people (marking the cherry picks would be the smallest
change for them I think but ICBW?) but I'd guess it would help everyone
doing merges.  You could always do frequent merges on a separate branch
and then redo everything for what gets sent to Linus so we don't end up
with excessive mechanical merges in history.

> Well, I was going to tell about the drm-tip, but that you already know.
> And yes, we cannot have that for-next because it contains topic branches
> we really don't want to send up.

> Dave, Sima, Jani, perhaps we could instrument dim to create a drm-for-next
> that is the merge of all of our relevant branches excluding the topic
> branches?

I think that's in the shape of what I'm suggesting above.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Krzysztof Kozlowski]

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

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Dave Airlie]

On Wed, 12 Aug 2026 at 16:01, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> 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...

Get back to me when their devices are in a place to be running
upstream kernels as much as AMD or Intel at the same scale.

We've tried to keep the upstream schedule for ages, as Rodrigo points
out it falls down, stuff goes missing in the shutdown periods, telling
teams to stop working for 2-3 weeks isn't an option in most companies.
Intel and AMD are trying to upstream GPUs that aren't even on the
market yet, velocity mattters a lot more because thier customers are
usually on the end of the pipeline via Linus' tree,

Qualcomm is not in the same position, a lot of their pipeline delivery
is via Android or ChromeOS and they have nowhere near the amount of
regression finding problems that upstream GPUs have.

small potatoes...

Dave.

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Krzysztof Kozlowski]

On 12/08/2026 08:20, Dave Airlie wrote:
> On Wed, 12 Aug 2026 at 16:01, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> 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...
> 
> Get back to me when their devices are in a place to be running
> upstream kernels as much as AMD or Intel at the same scale.

So I am back. All recent flagship SoCs since a 3-4 years have full
upstream patches posted from day 0 of hardware release. Since a year
Qualcomm upstreams most of the patches before hardware release.

And their devices is a SoC, consisting of not only GPU but few other
DSPs and multum of other IP blocks, so not even single hardware.

I am not saying that they are doing perfect, but they received clear
guideline they need to adjust to upstream process and cycle and they do
try to adjust. I know it from first hand since I have been directly
involved in this for a year now.

> 
> We've tried to keep the upstream schedule for ages, as Rodrigo points
> out it falls down, stuff goes missing in the shutdown periods, telling
> teams to stop working for 2-3 weeks isn't an option in most companies.

Well, we tell that Qualcomm and Qualcomm listens to maintainers. Are you
saying that others cannot listen to maintainers? That is a very bad
precedent, because now Qualcomm managers will get back to me and say
"why are you so harsh to us? can't we get some slack like others?"

> Intel and AMD are trying to upstream GPUs that aren't even on the
> market yet, velocity mattters a lot more because thier customers are

Same Qualcomm. Qualcomm posts patches all in public like 9 months before
hardware is going to be announced. Publicly announced, so availability
even later!

> usually on the end of the pipeline via Linus' tree,
> 
> Qualcomm is not in the same position, a lot of their pipeline delivery
> is via Android or ChromeOS and they have nowhere near the amount of
> regression finding problems that upstream GPUs have.

No true anymore. They do release to Android but that's downstream and we
do not talk about it here. I talk about upstream and their
upstream-first releases for all of their major and minor products.

That's mainline Linux distros: Debian, Ubuntu, Yocto. Their current BSP
is pure upstream based.

That's the same amount of regression handling as Intel and AMD.

Do not assume AMD and Intel are the only ones or are somehow special.


Best regards,
Krzysztof

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Greg KH]

On Wed, Aug 12, 2026 at 04:20:04PM +1000, Dave Airlie wrote:
> We've tried to keep the upstream schedule for ages, as Rodrigo points
> out it falls down, stuff goes missing in the shutdown periods, telling
> teams to stop working for 2-3 weeks isn't an option in most companies.
> Intel and AMD are trying to upstream GPUs that aren't even on the
> market yet, velocity mattters a lot more because thier customers are
> usually on the end of the pipeline via Linus' tree,

Why would anyone need to "stop working" for 2-3 weeks?  That's not what
other trees do, the patches just go into a different queue/tree until
the merge window is over and then they flow into the normal -next branch
(or whatever you want to call it.)

The only one that needs to worry about the merge window is the
maintainers.  Developers just need to be aware of "is this a new feature
or a bugfix", and all other subsystems seem to be able to enforce that
tiny rule, which guides which branch to apply a commit to.

Are GPU driver developers really not aware if they are fixing a bug or
not?  If not, who is doing the crazy cherry-pick in the first place?

And again, I hate how the DRM tree works, and I think overall you
greatly suffer for this model as the "Fixes:" tags all are wrong which
cause regression and CVE tracking to be totally broken for all
backports.  So I guess the teams for those 2 companies don't really care
about stable trees?  :)

thanks,

greg k-h

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Dave Airlie]

On Wed, 12 Aug 2026 at 17:43, Greg KH <greg@kroah.com> wrote:
>
> On Wed, Aug 12, 2026 at 04:20:04PM +1000, Dave Airlie wrote:
> > We've tried to keep the upstream schedule for ages, as Rodrigo points
> > out it falls down, stuff goes missing in the shutdown periods, telling
> > teams to stop working for 2-3 weeks isn't an option in most companies.
> > Intel and AMD are trying to upstream GPUs that aren't even on the
> > market yet, velocity mattters a lot more because thier customers are
> > usually on the end of the pipeline via Linus' tree,
>
> Why would anyone need to "stop working" for 2-3 weeks?  That's not what
> other trees do, the patches just go into a different queue/tree until
> the merge window is over and then they flow into the normal -next branch
> (or whatever you want to call it.)

Where is this magic tree, how do you keep CI on that tree, is there a
maintainer who isn't saying, I won't review stuff for 3 weeks because
the merge window is open, etc. There are plenty of examples of
maintainers not merging stuff into trees for weeks on end around
release->rc1 etc, shit developers get used to but it cuts their
velocity for upstream work. We've had plenty of examples of
development been taken in house and then upstreamed by separate teams
later, which is the result of what we previously did. I hate to sound
like an asshole, but we tried most of the things people with the 5-10
developers 5 years ago and 5 years ago before that, and they never
scaled out. There was always shit falling on the floor because of
various bottlenecks introduced by the upstream process vs what
internal teams were trying to deliver. Often you have internal teams
trying to deliver a coherent driver across non-upstream and when that
becomes easier or the priority upstream suffers from it.

> The only one that needs to worry about the merge window is the
> maintainers.  Developers just need to be aware of "is this a new feature
> or a bugfix", and all other subsystems seem to be able to enforce that
> tiny rule, which guides which branch to apply a commit to.

Maintainers care about the merge window, but also disappear or
shutdown progress in it, if you tell me this never happens, I've got a
number of bridges I'm selling.

> And again, I hate how the DRM tree works, and I think overall you
> greatly suffer for this model as the "Fixes:" tags all are wrong which
> cause regression and CVE tracking to be totally broken for all
> backports.  So I guess the teams for those 2 companies don't really care
> about stable trees?  :)

Hey you said very explicitly and in many forums in the past that
nobody needs to care about stable trees, not my fault if people
listen!

They are not aware if they are fixing a bug in Linux or Windows
sometimes, they might not know what Linux release they are fixing a
bug in, or what the state of backported patches to that tree are. They
also don't have access to CI for all of that. They also don't know
that rc6 fixes are different than rc2 fixes, and sending Linus an rc2
fix in rc7 is an internet fame earning offence.

There is a lot of subtley the smaller trees get away with if they do
one next and one or two fixes pulls to Linus. We send 1-2 next and a
fixes round for every rc for Intel and AMD, I'm lucky if I get one
batch of fixes out of qualcomm in the middle of the rc cycle. Despite
Kryzstof's efforts to convince otherwise, Qualcomm are small potatoes
from at least a GPU pov.

We have tried to fix Fixes: and tried to fix cherry-picking, and to be
honest I've lost track of the objections we've had from the same
people no matter which way we go.

It's possible to have a coherent view of things and Fixes can be made
to work, how do I know, because we deal with this inside of my
employer quite regularly.

Dave.

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 5232 bytes --]

On Wed, Aug 12, 2026 at 06:05:32PM +1000, Dave Airlie wrote:
> On Wed, 12 Aug 2026 at 17:43, Greg KH <greg@kroah.com> wrote:

> > Why would anyone need to "stop working" for 2-3 weeks?  That's not what
> > other trees do, the patches just go into a different queue/tree until
> > the merge window is over and then they flow into the normal -next branch
> > (or whatever you want to call it.)

> Where is this magic tree, how do you keep CI on that tree, is there a
> maintainer who isn't saying, I won't review stuff for 3 weeks because
> the merge window is open, etc. There are plenty of examples of

I certainly don't stop looking at stuff, nor do I tell people to stop
sending me stuff.  Currently I don't end up applying non-fix things but
it tends to be in the space where I'm leaving stuff on the list anyway
to give other people a chance to review, it never really seemed to be
causing anyone too many issues.  Since I switched to b4 to drive my
review I might actually start just applying stuff again, I mainly
stopped because it used to flow a bit more neatly with my own scripts.
When I'm not applying stuff I'm generally queueing it, it all gets
dropped into the tree once -rc1 appears and then gets into the tree as
my CI recovers from the onslaught.  When I did actually apply things I
did exactly what drm is doing and just appply them to a branch that
didn't get pushed into -next, my scripting still has all the bits for
that so I'd just have to open the new branch to restart.

Keeping CI available seems like one of the more trivial problems, just
point the CI at a for-ci branch that merges whatever should be CIed or
something.

> maintainers not merging stuff into trees for weeks on end around
> release->rc1 etc, shit developers get used to but it cuts their
> velocity for upstream work. We've had plenty of examples of

That's definitely a thing for some trees, and there's some trees that
close down betwen say -rc6 and -rc3 which is a very big window and I do
feel not ideally helpful.  That length of shutdown is unusual though,
and my inbox tells me that there's plenty of development and review
activity going on during the merge window.

> development been taken in house and then upstreamed by separate teams
> later, which is the result of what we previously did. I hate to sound
> like an asshole, but we tried most of the things people with the 5-10
> developers 5 years ago and 5 years ago before that, and they never
> scaled out. There was always shit falling on the floor because of
> various bottlenecks introduced by the upstream process vs what
> internal teams were trying to deliver. Often you have internal teams
> trying to deliver a coherent driver across non-upstream and when that
> becomes easier or the priority upstream suffers from it.

I think you're overindexing on how much of a snowflake DRM is here TBH,
of course DRM is at the upper end of all the various scaling issues but
there seems to be this big disconnect where you're assuming no other
maintainers can relate to anything you're seeing at all.

> There is a lot of subtley the smaller trees get away with if they do
> one next and one or two fixes pulls to Linus. We send 1-2 next and a
> fixes round for every rc for Intel and AMD, I'm lucky if I get one
> batch of fixes out of qualcomm in the middle of the rc cycle. Despite
> Kryzstof's efforts to convince otherwise, Qualcomm are small potatoes
> from at least a GPU pov.

I dunno, I find myself sending fixes most -rcs.  It really should be all
of them but sometimes I don't get round to it in time or there's
something I want to let cook a bit longer.  I don't think that's super
weird?  

> We have tried to fix Fixes: and tried to fix cherry-picking, and to be
> honest I've lost track of the objections we've had from the same
> people no matter which way we go.

It might help if someone could write down what's been tried somewhere
people can refer to, that way people could link to that and give a
clearer explanation of things instead of the briefer replies that tend
to happen.  It'd also be a useful reference for people considering
updating their workflows, perhaps there should be some central idea
sharing place for this sort of thing.

It'd also help if there were some work on mitigations for the externally
visible impacts of the unusual workflows drm is adopting.  For example,
I've mentioned the idea of marking the cherry picks as being cherry
picks.  That would help me a bit and I think also the stable people (if
a cherry pick gets tagged as being fixed they could then find the
original commit).  It's difficult to think why it would not be possible
to do this, and it should be low enough effort that even if it only
helps a little it'd be worth it.

Personally I'd also really appreciate it if the branches drm is pushing
into -next had the merges with the fixes branches already done, I
believe those merges do end up happening anyway and it would save me a
huge amount of time.  That's a bit more specialist but others have
mentioned that they also end up merging drm's development branches for
non-next stuff so it wouldn't *just* be me.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Dave Airlie]

On Wed, 12 Aug 2026 at 09:10, Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Aug 11, 2026 at 03:54:38PM -0400, Rodrigo Vivi wrote:
>
> > 1. Increase the risk of hic-ups in other fronts. For instance: patches
> > that should had been merged to -fixes only going to next and forgotten
> > to be ported to the previous version. And patches that should be new
> > features due to the risk of regression, added to the previous version.
>
> > But here one could argue that in a distributed commit rights flow, this
> > is exactly why maintainers role is more critical, tto ensure we are not
> > missing anything and that the patches are moved to the right place.
> > Fair enough, but this makes our hashes more likely to change. We try
> > to keep the non-rebasing tree to avoid disruptions in OSVs and many
> > other teams that are consuming our trees.
>
> I don't think cherry picking if something gets misdirected would be the
> end of the world, it's more the fact that you're both doing it as the
> normal and default thing and never marking the cherry picks as such that
> causes issues.

So I remember some of the problem, if you cherry-pick with -x the
complaint was we had commits in -fixes with a cherry-pick commit id
that wasn't in Linus' tree at that time.

It would of course later materialise in Linus' tree when the next
merge window occurred since we don't rebase, but this either broke
people's brains or scripts badly enough we got push back on it.

I think we should definitely do -x on all cherry-picks and I'll push
to make sure we start doing it again.

>
> > 2. The conflicts would happen anyway. I still see a lot of conflicts
> > in the drm-misc flow.
>
> > 3. Harder to manage the conflicts. Our cherry-pick flow brings some very
> > obvious conflict resolution to the table. If you are in a newer kernel
> > you likely only need to go with it is already in our -next branches,
> > if you are in the current -rc based you likely need to go with what
> > it ported to -fixes. It really is not something complicated to solve.
> > But if you go with a flow that the patches don't have the same baseline
> > like we have the -next and our -tip, then you get harder conflicts to
> > solve and likely to make more mistakes.
>
> The conflicts that I'm seeing from drm are I would say the hardest to
> follow, certainly by far the hardest to follow that I see on such a
> frequent and routine basis.  They are often huge because of the lack of
> shared history between the two branches, there's often enormous sets of
> changes on both sides (not helped by all the unadvertised duplication
> making the divergent histories bigger) and there's no structure or
> explanation for what's going on.  It's all a huge mess, and as a result
> it's the area where I make most mistakes and end up having to do time
> consuming stuff like repeat builds and merges.
>
> You do sometimes see more complicated things, I do occasionally end up
> doing things like just hold a change at an old version and ask for help,
> but it's more like once every couple of releases rather than several
> times a week.  However with those more complicated cases understanding
> what the conflict is tends to be a lot simpler, you can generally see
> the two sets of changes and what they're trying to accomplish quite
> easily, and the complexity comes from colliding semantic changes in an
> unfamiliar area of code.  The fact that with these cases the developers
> concerned are usually surprised to learn of the conflict does help a lot
> too.
>
> I think from a -next point of view the smallest change that would help
> would be if the -next branches you were publishing had all your -fixes
> branches and Linus' tree already merged up up, that way any conflicts
> that do come up would be actual conflicts with other things rather than
> just the rountine conflict spam that should just have been a merge
> instead of a cherry pick in the first place.  I believe that this is
> what happens before the drm changes get sent to Linus.  That wouldn't
> help the stable people (marking the cherry picks would be the smallest
> change for them I think but ICBW?) but I'd guess it would help everyone
> doing merges.  You could always do frequent merges on a separate branch
> and then redo everything for what gets sent to Linus so we don't end up
> with excessive mechanical merges in history.

I'm going to look into giving next a tree with fixes merged into it,
it's non-trivial even for our dim managed trees which are the main
drm, drm-misc and intel trees, since currently drm-tip is all of the
above + CI bandaids, but we could probably construct an offramp in dim
to create a merged tree using the rerere cache.

Dave.

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

On Thu, Aug 13, 2026 at 06:33:05AM +1000, Dave Airlie wrote:

> So I remember some of the problem, if you cherry-pick with -x the
> complaint was we had commits in -fixes with a cherry-pick commit id
> that wasn't in Linus' tree at that time.

> It would of course later materialise in Linus' tree when the next
> merge window occurred since we don't rebase, but this either broke
> people's brains or scripts badly enough we got push back on it.

> I think we should definitely do -x on all cherry-picks and I'll push
> to make sure we start doing it again.

That'd be helpful, thanks -  I guess you're going to annoy someone
either way unfortunately but at least the commit not in mainline issue
would be transient.

> I'm going to look into giving next a tree with fixes merged into it,
> it's non-trivial even for our dim managed trees which are the main
> drm, drm-misc and intel trees, since currently drm-tip is all of the
> above + CI bandaids, but we could probably construct an offramp in dim
> to create a merged tree using the rerere cache.

Thanks for this also - another idea might be to order the stuff that
isn't for -next at the end of the merge, and push the tree out as a
separate branch before carrying on with the non-next bits (like how
pending-fixes is done)?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Jani Nikula]

On Thu, 13 Aug 2026, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Aug 13, 2026 at 06:33:05AM +1000, Dave Airlie wrote:
>
>> So I remember some of the problem, if you cherry-pick with -x the
>> complaint was we had commits in -fixes with a cherry-pick commit id
>> that wasn't in Linus' tree at that time.
>
>> It would of course later materialise in Linus' tree when the next
>> merge window occurred since we don't rebase, but this either broke
>> people's brains or scripts badly enough we got push back on it.
>
>> I think we should definitely do -x on all cherry-picks and I'll push
>> to make sure we start doing it again.
>
> That'd be helpful, thanks -  I guess you're going to annoy someone
> either way unfortunately but at least the commit not in mainline issue
> would be transient.

We use the drm subsystem maintainer tool for cherry-picks, and it uses
the -x option.

If you have any suggestions for helpful but non-intrusive additional
annotations on cherry-picked commits, it should be easy enough to update
the tool. And perhaps the annotation could be more widely adopted as
well. It's not like nobody else ever cherry-picks, we just do it
more. The annotation could still be the same.

BR,
Jani.


-- 
Jani Nikula, Intel

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Liam R. Howlett]

On 26/08/10 08:14PM, Theodore Tso wrote:
> On Mon, Aug 10, 2026 at 04:35:48PM -0500, Liam R. Howlett wrote:
> > 
> > I don't want to be invited.  My only reason for being vocal is to
> > facilitate process improvements.
> 
> Liam, do you have any concrete process improvements that you'd like
> propose?
> 

When succession is happening, it would be good to have the new person
shadow the outgoing person.

Thanks,
Liam

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Theodore Tso]

On Tue, Aug 18, 2026 at 09:09:22AM -0500, Liam R. Howlett wrote:
> 
> When succession is happening, it would be good to have the new person
> shadow the outgoing person.

That's a good idea, where it's possible.  Have you suggested this to
David and Andrew?  I know there are a lot of discussions about the
succession within the mm subsystem, and since it's (from an outsider's
perspective), it's a large and very healthy community, my personal
preference would be to let the mm subsystem work through this
succession, and then we can take learnings a year or so after the
succession is complete.

Cheers,

					- Ted

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[David Hildenbrand (Arm)]

On 8/18/26 16:02, Theodore Tso wrote:
> On Tue, Aug 18, 2026 at 09:09:22AM -0500, Liam R. Howlett wrote:
>>
>> When succession is happening, it would be good to have the new person
>> shadow the outgoing person.
> 
> That's a good idea, where it's possible.  Have you suggested this to
> David and Andrew?  I know there are a lot of discussions about the
> succession within the mm subsystem, and since it's (from an outsider's
> perspective), it's a large and very healthy community, my personal
> preference would be to let the mm subsystem work through this
> succession, and then we can take learnings a year or so after the
> succession is complete.

I am not sure why we are suddenly discussing the MM transition here.

Liam, do you see a particular problem in the way we are currently tackling the
transition? Or was that just a general comment, independent of the MM thingy?

-- 
Cheers,

David

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Lorenzo Stoakes (ARM)]

On Mon, Aug 10, 2026 at 08:14:51PM -0400, Theodore Tso wrote:
> On Mon, Aug 10, 2026 at 04:35:48PM -0500, Liam R. Howlett wrote:
> >
> > I don't want to be invited.  My only reason for being vocal is to
> > facilitate process improvements.
>
> Liam, do you have any concrete process improvements that you'd like
> propose?

(Since this thread popped up again...)

TBF I did make concrete process suggestions myself here:

https://lore.kernel.org/all/anntucHhrzF_b4sy@lucifer/

And here (documentation):

https://lore.kernel.org/all/anntucHhrzF_b4sy@lucifer/

(I also repeated both in a couple places)

And they got ignored, so I'm not _entirely_ sure that's what you guys are after
here :)

It seemed like the thread digressed rather and all will be forgotten again until
next it comes up...

>
> Thanks,
>
> 						- Ted

--
Cheers, Lorenzo

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Lorenzo Stoakes (ARM)]

On Tue, Aug 18, 2026 at 03:51:22PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Mon, Aug 10, 2026 at 08:14:51PM -0400, Theodore Tso wrote:
> > On Mon, Aug 10, 2026 at 04:35:48PM -0500, Liam R. Howlett wrote:
> > >
> > > I don't want to be invited.  My only reason for being vocal is to
> > > facilitate process improvements.
> >
> > Liam, do you have any concrete process improvements that you'd like
> > propose?
>
> (Since this thread popped up again...)
>
> TBF I did make concrete process suggestions myself here:
>
> https://lore.kernel.org/all/anntucHhrzF_b4sy@lucifer/
>
> And here (documentation):
>
> https://lore.kernel.org/all/anntucHhrzF_b4sy@lucifer/

Oops sorry I made both suggestions in the same place...

>
> (I also repeated both in a couple places)

...but I did re-reference them in a couple places too. Alas to no avail :)

>
> And they got ignored, so I'm not _entirely_ sure that's what you guys are after
> here :)
>
> It seemed like the thread digressed rather and all will be forgotten again until
> next it comes up...
>
> >
> > Thanks,
> >
> > 						- Ted
>
> --
> Cheers, Lorenzo

--
Cheers, Lorenzo

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Liam R. Howlett]

On 26/08/18 04:21PM, David Hildenbrand (Arm) wrote:
> On 8/18/26 16:02, Theodore Tso wrote:
> > On Tue, Aug 18, 2026 at 09:09:22AM -0500, Liam R. Howlett wrote:
> >>
> >> When succession is happening, it would be good to have the new person
> >> shadow the outgoing person.
> > 
> > That's a good idea, where it's possible.  Have you suggested this to
> > David and Andrew?  I know there are a lot of discussions about the
> > succession within the mm subsystem, and since it's (from an outsider's
> > perspective), it's a large and very healthy community, my personal
> > preference would be to let the mm subsystem work through this
> > succession, and then we can take learnings a year or so after the
> > succession is complete.

I haven't brought it up with Andrew and David, but we do have meetings
about what's going on - although I might have missed one due to time off
recently.

It seems like a good idea to have the shadow option opened for
transitioning and it seems worth bringing up as a process change in its
own right.

> 
> I am not sure why we are suddenly discussing the MM transition here.
> 
> Liam, do you see a particular problem in the way we are currently tackling the
> transition? Or was that just a general comment, independent of the MM thingy?

I was more thinking of a process change, in general.  Even if it's a
note saying 'if you have a known transition of ownership coming, let us
know".

The committee is looking at how to draw a line on the people to go and
leave everything else up to the subsystem maintainers.  This assumes the
committee knows succession planning and actions in the subsystems and
that they keep it top of mind.

There's also the point raised about more changes on the horizon, so we
either make it a part of the process, trust the succession planning
takes MS into account a year (or more) ahead of time, or risk a number
of first timers at MS.

Thanks,
Liam

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Theodore Tso]

On Tue, Aug 18, 2026 at 03:51:16PM -0500, Lorenzo Stoakes (ARM) wrote:
> TBF I did make concrete process suggestions myself here:
> 
> https://lore.kernel.org/all/anntucHhrzF_b4sy@lucifer/
> 
> And here (documentation):
> 
> https://lore.kernel.org/all/anntucHhrzF_b4sy@lucifer/

These are the same URL; cut and paste error?

> And they got ignored, so I'm not _entirely_ sure that's what you
> guys are after here :)

The above message was essentially a suggestion to (a) improve the
Maintainer Summit Call for Topics, and (b) document the full process,
with all of the details in the Documentation directory.  The first is
something that wasn't immediately actionable --- it's something to do
for next year, and the second is one that we could do eventually, but
to be honest, it didn't seem super urgent given that it's documented
in this e-mail thread, and many of us have other things with shorter
timelines (such as the merge window) that is keeping us busy.

I'm sorry that you feel ignored, but we all have tons and tons on our
things screaming for our attention.

Cheers,

						- Ted

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

On Tue, Aug 18, 2026 at 12:38:08PM +0300, Jani Nikula wrote:
> On Thu, 13 Aug 2026, Mark Brown <broonie@kernel.org> wrote:

> > That'd be helpful, thanks -  I guess you're going to annoy someone
> > either way unfortunately but at least the commit not in mainline issue
> > would be transient.

> We use the drm subsystem maintainer tool for cherry-picks, and it uses
> the -x option.

Ah, so they are - I did do a spot check but it looks like I managed to
find some of the few directly applied fixes.  I think I usually miss
the cherry-pick -x annotations because they end up buried in the block
of signoff information.  Sorry about that.

> If you have any suggestions for helpful but non-intrusive additional
> annotations on cherry-picked commits, it should be easy enough to update
> the tool. And perhaps the annotation could be more widely adopted as
> well. It's not like nobody else ever cherry-picks, we just do it
> more. The annotation could still be the same.

The stable ones where the annotation goes at the top of the changelog
are a bit more noticable?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[James Bottomley]

On Tue, 2026-08-18 at 12:45 -0400, Theodore Tso wrote:
> I'm sorry that you feel ignored, but we all have tons and tons on our
> things screaming for our attention.

I suggested what I thought were three actionable discussion topics that
didn't get much traction either:

https://lore.kernel.org/all/215b3cdfda17207d91b0fa057b01f3cb45eb874c.camel@HansenPartnership.com/

Regards,

James

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Lorenzo Stoakes (ARM)]

On Tue, Aug 18, 2026 at 12:45:52PM -0400, Theodore Tso wrote:
> On Tue, Aug 18, 2026 at 03:51:16PM -0500, Lorenzo Stoakes (ARM) wrote:
> > TBF I did make concrete process suggestions myself here:
> >
> > https://lore.kernel.org/all/anntucHhrzF_b4sy@lucifer/
> >
> > And here (documentation):
> >
> > https://lore.kernel.org/all/anntucHhrzF_b4sy@lucifer/
>
> These are the same URL; cut and paste error?

Yup sorry I hadn't realised I'd made both points in the same email :)

>
> > And they got ignored, so I'm not _entirely_ sure that's what you
> > guys are after here :)
>
> The above message was essentially a suggestion to (a) improve the
> Maintainer Summit Call for Topics, and (b) document the full process,
> with all of the details in the Documentation directory.  The first is
> something that wasn't immediately actionable --- it's something to do
> for next year, and the second is one that we could do eventually, but
> to be honest, it didn't seem super urgent given that it's documented
> in this e-mail thread, and many of us have other things with shorter
> timelines (such as the merge window) that is keeping us busy.
>
> I'm sorry that you feel ignored, but we all have tons and tons on our
> things screaming for our attention.

I mean honestly that isn't very convincing - the entire thread was
low-priority and we're all very very busy.

So I'll eat my hat if either of those suggestions ever actually get
actioned :) [or you can choose a suitable actually edible alternative if
you hold me to this ;)]

It's all rather embelmatic of the MS as a whole - appearance of community
but structurally not that. And what complicate it is that it probably _has_
to be that way for things to be functional, as discussed ad infinitum in
these threads.

I do still feel that we should just be honest about that (that's what my
suggestions were about), but you know, hat, fork :)

>
> Cheers,
>
> 						- Ted

--
Cheers, Lorenzo

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Theodore Tso]

On Tue, Aug 18, 2026 at 11:32:07AM -0500, Liam R. Howlett wrote:
> The committee is looking at how to draw a line on the people to go and
> leave everything else up to the subsystem maintainers.  This assumes the
> committee knows succession planning and actions in the subsystems and
> that they keep it top of mind.

I suspect that for major subsystems, if it *can* be planned, everyone
will know about it.  I didn't want to talk about the details of
internal deliberations of the program committee, but it's safe to say
that Linus explicitly mentioned it, it was discussed by the program
committee, and we extended invitations to both Andrew and David.

There were people on this thread that seemed to assume that the
program committee had completely ignored the situation, but that
wasn't the case.

> There's also the point raised about more changes on the horizon, so we
> either make it a part of the process, trust the succession planning
> takes MS into account a year (or more) ahead of time, or risk a number
> of first timers at MS.

Personally, I'm not worried about first timers; in fact, having a
first timers is a *feature* not a bug.  The opposite is the complaint
that it's always the same "clique" attending the Maintainers Summit.

As long as the new subsystem maintainers are experienced kernel
engineers, that's the most important issue.  As far as process
concerns, as long as major subsystems give a heads to Linus (not to
mention discussions at LSF/MM, or Plumbers, both of which have
happened with different senior developers planning their upcoming
retirement), I don't think we really need to worry about the community
getting taken by surprise.  So if things aren't broken, I'd argue that
we not add more formal procedures where they might not be necessary.

Cheers,

						- Ted

Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?

[Lorenzo Stoakes (ARM)]

On Tue, Aug 18, 2026 at 01:46:15PM -0400, Theodore Tso wrote:
> > There's also the point raised about more changes on the horizon, so we
> > either make it a part of the process, trust the succession planning
> > takes MS into account a year (or more) ahead of time, or risk a number
> > of first timers at MS.
>
> Personally, I'm not worried about first timers; in fact, having a
> first timers is a *feature* not a bug.  The opposite is the complaint
> that it's always the same "clique" attending the Maintainers Summit.

I mean it feels like you're batting things off again here :) if you want
more first timers you would have to make changes, your analysis on that was
rather flawed, another point which wasn't addressed:

"That puts the number of seats filled by one-time attendees at any
conference at 21.6%, not 44.9%."

http://lore.kernel.org/all/anii3u-87kSrB9K3@lucifer

>
> Cheers,
>
> 						- Ted

--
Cheers, Lorenzo