Linux Kernel Continuity Document Added: What Happens If Torvalds' Git Repo Goes Away?

The Linux kernel's development process is famously distributed. Over 100 maintainers manage their own subsystem trees, pulling changes from contributors and pushing them upward through a hierarchy of repositories. The final step, however, is centralized: Linus Torvalds' personal Git repository at torvalds/linux.git serves as the canonical source for the mainline kernel.

This structure has proven resilient. In 2018, when Torvalds took a brief hiatus during the 4.19 release cycle, trusted lieutenants like Greg Kroah-Hartman and Sasha Levin were able to step in and manage the merge window. The system worked because the process was already understood. Now, following discussions at the 2025 Linux Maintainer Summit, the project has formalized that understanding into official documentation.

Merged overnight into the Linux 6.19 development tree, the new Linux project continuity document provides a step-by-step plan for what happens if Torvalds' Git repository becomes unavailable or if he becomes unable to continue his role. The document, drafted by Linux engineer Dan Williams, is not about predicting a specific event but about ensuring the project's long-term health through a clear, pre-defined process.

The 72-Hour Response Protocol

The core of the document is a timeline and responsibility chain. The process is triggered if the maintainers of the top-level repository become "unwilling or unable to do that work going forward." The key actor is designated as $ORGANIZER, which is defined as the last Maintainer Summit organizer or, as a backup, the current Linux Foundation (LF) Technical Advisory Board (TAB) Chair.

Here is the formalized sequence:

1. Within 72 hours, $ORGANIZER must open a discussion with the invitees of the most recently concluded Maintainers Summit.
2. A meeting will be scheduled as soon as possible, either online or in-person, aiming to maximize participant attendance.
3. If no Maintainer Summit has occurred in the last 15 months, the TAB will determine the invitee list for this emergency meeting.
4. Invitees may bring in other maintainers as needed, ensuring the right expertise is present.
5. The meeting, chaired by $ORGANIZER, will evaluate options for managing the top-level repository, with the primary goal of maximizing the project's long-term health.
6. Within two weeks, a representative from this group must communicate the next steps to the broader community via the [email protected] mailing list.
7. The Linux Foundation, guided by the TAB, will then take the necessary steps to implement the chosen plan.

Why This Matters: The Git Repository as a Single Point of Failure

While the Linux kernel development model is highly distributed, the final integration point is not. The torvalds/linux.git repository is the single source of truth for the mainline kernel. All other trees, from subsystem maintainers to Greg Kroah-Hartman's stable trees, ultimately trace back to this repository.

This creates a theoretical single point of failure. If this repository were to become permanently inaccessible—whether due to a technical failure, a lost key, or a more serious incident—the project could face significant disruption. The continuity document mitigates this risk by:

• Eliminating ambiguity: It removes any guesswork about who should act and when.
• Leveraging existing governance: It uses the existing structures of the Maintainer Summit and the TAB, avoiding the need to create a new committee from scratch.
• Ensuring community buy-in: By involving a broad group of senior maintainers, any transition plan will have the credibility needed for the community to accept it.

Historical Precedent and Technical Implementation

The 2018 4.19 release was a real-world test of the community's ability to handle Torvalds' absence. The process was ad-hoc but effective. This new document codifies that ad-hoc process into a formal procedure.

Technically, the Git repository itself is replicated across many mirrors. The Linux Foundation hosts official mirrors, and countless developers and companies have their own copies. The challenge isn't the loss of the data, but the loss of the canonical authority. If the official torvalds/linux.git were to vanish, the community would need to quickly agree on a new canonical source. The continuity plan provides the framework for that agreement.

The document is now part of the kernel's official documentation, residing in the kernel's source tree. It serves as a reminder that while the Linux kernel is a massive, complex technical artifact, its governance is built on clear processes and community trust. The addition of this continuity plan strengthens that foundation, ensuring that the kernel can continue to evolve no matter what happens to its most visible leader.

For those interested in the full text of the document, it is available in the Linux kernel Git repository. The merge commit for this change can be found in the Linux 6.19 development tree.