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

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

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

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

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

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

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

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

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

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

[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)]

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

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

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

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

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

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

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

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

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

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

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

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

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

[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 --]

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?

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

[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

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?

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

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

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

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

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

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

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

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

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

[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: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