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

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