From: "Theodore Tso" <tytso@mit.edu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?
Date: Sat, 8 Aug 2026 21:51:13 -0400 [thread overview]
Message-ID: <anfUgiByUVffXlrQ@mit.edu> (raw)
In-Reply-To: <CAHk-=wi734UD_CKkmRwZJHnNXAPTzYASXFh_XR092BsgWs8Qng@mail.gmail.com>
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
next prev parent reply other threads:[~2026-08-09 1:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 15:34 [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit? James Bottomley
2026-08-06 23:41 ` Steven Rostedt
2026-08-07 13:53 ` Rafael J. Wysocki (Intel)
2026-08-07 14:53 ` Steven Rostedt
2026-08-07 16:33 ` James Bottomley
2026-08-07 17:27 ` Linus Torvalds
2026-08-07 19:03 ` James Bottomley
2026-08-07 19:51 ` Steven Rostedt
2026-08-07 20:12 ` Shuah Khan
2026-08-09 1:51 ` Theodore Tso [this message]
2026-08-07 12:58 ` Laurent Pinchart
2026-08-07 13:09 ` James Bottomley
2026-08-07 13:28 ` Laurent Pinchart
2026-08-07 20:15 ` H. Peter Anvin
2026-08-07 19:15 ` Chris Mason
2026-08-07 19:53 ` Steven Rostedt
2026-08-07 23:19 ` Theodore Tso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anfUgiByUVffXlrQ@mit.edu \
--to=tytso@mit.edu \
--cc=James.Bottomley@hansenpartnership.com \
--cc=ksummit@lists.linux.dev \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.