Welcome to LWN.net
The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net!
The final part of the 2025 Maintainers Summit was devoted to the kernel's development process itself. There were two sessions, one on continuity and succession planning, and the traditional discussion, led by Linus Torvalds, on any pain points that the community is experiencing. There was not a lot that developers were unhappy about, and there are now more explicit plans in the works to provide a process should Torvalds abruptly become unable to fill his role.
Succession planning
The succession topic was addressed first in a session led by Dan Williams;
he described it as an uplifting subject tied to "our eventual march
toward death
", and offered to talk about Link tags instead if it got to be too much.
More seriously, he pointed out that people do worry about what might ensue
if something were to happen to Torvalds without a designated successor in
place, and wanted to talk about a potential way to address those concerns.
![[Dan Williams]](https://static.lwn.net/images/conf/2025/ossjp/DanWilliams-sm.png "Dan Williams")
The details of this discussion will mostly be left out; it is sufficient to
say that there was not a lot of disagreement in the room. There were two
noteworthy outcomes at the end.
The first is that some provisions for disaster have been made, in that there are multiple people who have the ability to commit to Torvalds's repository, and there is redundancy for the stable repository as well. There is not a single point of failure there that would force a move to another repository just to keep the kernel releases coming.
In the most likely scenario, Torvalds will eventually decide that it is time to move on, and will arrange for a smooth transition to his replacement. He let it be known, though, that he has recently signed a new contract with the Linux Foundation and does not intend to go away anytime soon.
It was agreed that there should be a process in place to decide on a path forward should something happen that prevents a smooth transition. As I put it in the discussion, in the absence of an agreed-upon process, the community would find itself playing Calvinball at an awkward time.
Williams had a proposal for that process: should the need arise, the attendees of the most recent Maintainers Summit would be brought together to collectively decide what happens next. Those attendees are a group that is trusted by both Torvalds and the community as a whole, and would have the breadth of vision needed to make a good decision. That decision could be the appointment of a new benevolent dictator, or it could be a transition to some sort of group maintainership. Dave Airlie suggested that the group should be locked in a room with the ability to send out white smoke when a decision has been reached.
The plan is for Williams to write up a proposed process document, which would first go through review by the Technical Advisory Board and (presumably) Torvalds. After that, it will be posted for discussion within the community as a whole.
The state of the development process
The traditional title for the final session is "Is Linus happy?". This
time around, he began by saying that he has not been seriously unhappy
about the process for a long time. When he is unhappy, people tend
to know about it, and the technical press writes about it. But he does not
like it when other developers are unhappy with the process. For
that reason, he said, the events in August and September (he was referring
obliquely to the removal of bcachefs from
the kernel) were not fun for him. Williams described that episode as a
"perfect storm
" that hadn't happened before in the community and,
hopefully, will not happen again.
![[Linus Torvalds]](https://static.lwn.net/images/conf/2025/ossjp/LinusTorvalds-sm.png "Linus Torvalds")
Torvalds said that he sometimes gets complaints about the kernel
community's use of email and "other old ways
", but that people
generally think that the model is working. Greg Kroah-Hartman said that
the kernel project's rate of change still exceeds that of any other
project; when projects start to approach the kernel's scale, they come and
ask on how to put together a process that works as well. Torvalds said he
didn't really see any big changes that he would want to make.
Konstantin Ryabitsev said that it is not possible to avoid using email.
Even developers using the Git-forge systems depend on email for
notifications and such. He is hoping that he can eventually develop the
lore archive into a sort of "message bus
" that might enable the
kernel community to leave email behind and "leapfrog the forge
stage
" entirely.
Airlie said that email is no longer a reliable message transport mechanism, and that corporate email systems often cannot be used for kernel development. Kroah-Hartman pointed out, though, that each kernel release features the work of at least 200 first-time contributors, so people are figuring out how to make email work for them. Ryabitsev observed that email is not the hardest part of kernel programming.
There was talk of wanting better continuous-integration systems, and some equivalent to GitHub's Actions. Alexei Starovoitov complained that he frequently runs into the limits of what GitHub is willing to provide. Christian Brauner said that the community needs a good test infrastructure that is not tied to any specific employer.
Airlie said that freedesktop.org has managed to solve a lot of these problems, but it was not easy. The first step is to put together high-quality tooling that solves problems; once that has been done, the painful process of finding sponsors to support the system becomes more tractable. It worked out for freedesktop.org, but would probably be harder to do for the whole kernel, he said.
The session was winding down when the suggestion was made that it would be
nice to have some sort of continuous-integration capability within
kernel.org. Ryabitsev said that kernel.org is a charitable organization
with a specific mission, and that providing that sort of service would fall
outside the bounds, so he thinks that KernelCI would be a better home.
| Index entries for this article | |
|---|---|
| Conference | Kernel Maintainers Summit/2025 |