Stephen Rothwell, who has maintained the kernel's linux-next integration tree from its inception, has announced his retirement from that role:

I will be stepping down as Linux-Next maintainer on Jan 16, 2026. Mark Brown has generously volunteered to take up the challenge. He has helped in the past filling in when I have been unavailable, so hopefully knows what he is getting in to. I hope you will all treat him with the same (or better) level of respect that I have received.

It has been a long but mostly interesting task and I hope it has been helpful to others. It seems a long time since I read Andrew Morton's "I have a dream" email and decided that I could help out there - little did I know what I was heading for.

Over the last two decades or so, the kernel's development process has evolved from an unorganized mess with irregular releases to a smooth machine with a new release every nine or ten weeks. That would not have happened without linux-next; thanks are due to Stephen for helping to make the current process possible.

Linus Torvalds is famously averse to presenting prepared talks, but the wider community is always interested in what he has to say about the condition of the Linux kernel. So, for some time now, his appearances have been in the form of an informal conversation with Dirk Hohndel. At the 2025 Open Source Summit Japan, the pair followed that tradition for the 29th time. Topics covered include the state of the development process, what Torvalds actually does, and how machine-learning tools might fit into the kernel project.

Inside this week's LWN.net Weekly Edition:

• Front: Civil Infrastructure Platform; COSMIC desktop; Calibre adds AI; Maintainer's Summit; ML tools for kernel development; linux-next; Rust in the kernel; kernel development tools; Linux process improvements; 6.19 merge window part 2.
• Briefs: capsudo; Asahi Linux 6.18; Pop!_OS 24.04; Vojtux; KDE Gear 25.12; Rust 1.92.0; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

The Civil Infrastructure Platform (CIP) first launched in that form in April 2016, so it has a tenth-anniversary celebration in its near future. At the 2025 Open Source Summit Japan, Yoshitake Kobayashi talked about the goals of this project and where it is headed in the future. Supporting a Linux system for even one year is a challenging task; maintaining that support for a decade or more is rather more so, and a changing regulatory environment complicates the task further.

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.

Despite depending heavily on tools, the kernel project often seems to under-invest in the development of those tools. There has been progress in that area, though. At the 2025 Maintainers Summit, Konstantin Ryabitsev, who is (among other things) the author of b4, led a session on ways in which the kernel's tools could be improved to make the development process more efficient and accessible.

Linus Torvalds released 6.19-rc1 and closed the 6.19 merge window on December 14 (Japan time), after having pulled 12,314 non-merge commits into the mainline. Over 8,000 of those commits came in after our first 6.19 merge-window summary was written. The second part of the merge window was focused on drivers, but brought in a number of other changes as well.

Linus has released 6.19-rc1, perhaps a bit earlier than expected.

So it's Sunday afternoon in the part of the world where I am now, so if somebody was looking at trying to limbo under the merge window timing with one last pull request and is taken by surprise by the slightly unusual timing of the rc1 release, that failed.

Teaching moment, or random capricious acts? You be the judge.

Ariadne Conill is exploring a capability-based approach to privilege escalation on Linux systems.

Inspired by the object-capability model, I've been working on a project named capsudo. Instead of treating privilege escalation as a temporary change of identity, capsudo reframes it as a mediated interaction with a service called capsudod that holds specific authority, which may range from full root privileges to a narrowly scoped set of capabilities depending on how it is deployed.

The ability to write kernel code in Rust was explicitly added as an experiment — if things did not go well, Rust would be removed again. At the 2025 Maintainers Summit, a session was held to evaluate the state of that experiment, and to decide whether the time had come to declare the result to be a success. The (arguably unsurprising) conclusion was that the experiment is indeed a success, but there were some interesting points made along the way.

One of the key components in the kernel's development process is the linux-next repository. Every day, a large number of branches, each containing commits intended for the next kernel development cycle, is pulled into linux-next and integrated. If there are conflicts between branches, the linux-next process will reveal them. In theory, many other types of problems can be found as well. Some developers feel that linux-next does not work as well as it could, though. At the 2025 Maintainers Summit, Mark Brown, who helps to keep linux-next going, led a session on how it could be made to work more effectively.

The first topic of discussion at the 2025 Maintainers Summit has been in the air for a while: what role — if any — should machine-learning-based tools have in the kernel development process? While there has been a fair amount of controversy around these tools, and concerns remain, it seems that the kernel community, or at least its high-level maintainership, is comfortable with these tools becoming a significant part of the development process.

Inside this week's LWN.net Weekly Edition:

• Front: Rust in CPython; Python frozendict; Bazzite; IETF post-quantum disagreement; Distrobox; 6.19 merge window; Leaving the TAB.
• Briefs: Let's Encrypt retrospective; PKI infrastructure; Rust in kernel to stay; CNA series; Alpine 3.23.0; cmocka 2.0; Firefox 146; 2024 Free Software Awards; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

The topic of the Rust experiment was just discussed at the annual Maintainers Summit. The consensus among the assembled developers is that Rust in the kernel is no longer experimental — it is now a core part of the kernel and is here to stay. So the "experimental" tag will be coming off. Congratulations are in order for all of the Rust for Linux team.

(Stay tuned for details in our Maintainers Summit coverage.)

The Free Software Foundation has announced the recipients of its 2024 (even though 2025 is almost over) Free Software Awards. Andy Wingo won the award for the advancement of free software, Alx Sa is the outstanding new free-software contributor, and Govdirectory takes the award for projects of social benefit.

As has been recently announced, nominations are open for the 2025 Linux Foundation Technical Advisory Board (TAB) elections. I am one of the TAB members whose term is coming to an end, but I have decided that, after 18 years on the board, I will not be seeking re-election; instead, I will step aside and make room for a fresh voice. My time on the TAB has been rewarding, and I will be sad to leave; the TAB has an important role to play in the functioning of the kernel community.

As of this writing, 4,124 non-merge commits have been pulled into the mainline repository for the 6.19 kernel development cycle. That is a relatively small fraction of what can be expected this time around, but it contains quite a bit of significant work, with changes to many core kernel subsystems. Read on for a summary of the first part of the 6.19 merge window.

Version 2025.12 of the Home Assistant home-automation system has been released.

This month, we're unveiling Home Assistant Labs, a brand-new space where you can preview features before they go mainstream. And what better way to kick it off than with Winter mode? ❄️ Enable it and watch snowflakes drift across your dashboard. It's completely unnecessary, utterly delightful, and exactly the kind of thing we love to build. ❄️

But that's just the beginning. We've been working on making automations more intuitive over the past releases, and this release finally delivers purpose-specific triggers and conditions. Instead of thinking in (numeric) states, you can now simply say "When a light turns on" or "If the climate is heating". It's automation building the way our mind works, as it should be.

There are many possible programmer mistakes that are not caught by the minimal checks specified by the C language; among those is passing an array of the wrong size to a function. A recent attempt to add some safety around array parameters within the crypto layer involved the use of some clever tricks, but it turns out that clever tricks are unnecessary in this case. There is an obscure C feature that can cause this checking to happen, and it is already in use in a few places within the kernel.

Linus Torvalds released the 6.18 kernel as expected on November 30, closing the last full development cycle of 2025. It was another busy cycle, featuring a record number of developers. The time has come for a look at where the code came from for this kernel release, but also for the year-long long-term-support cycle which has also reached its conclusion with this release.