The Linux kernel does not follow a fixed release schedule dictated by calendar dates. Instead it uses a loosely time-based, rolling release model where a new major release happens every two or three months and contains roughly 13,000 changesets touching several hundred thousand lines of code. Understanding how that cycle works, and where your patches fit within it, is essential before you write your first line of kernel code.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/deelerdev/linux/llms.txt
Use this file to discover all available pages before exploring further.
The release cycle
A single development cycle moves through two distinct phases: the merge window and the stabilization period.Merge window opens
After a stable release ships, Linus Torvalds opens the merge window. Subsystem maintainers send pull requests for the patches they have already tested and staged. The kernel absorbs roughly 1,000 patches per day during this period. The window stays open for approximately two weeks.
rc1 is tagged
When Linus closes the merge window he tags the first release candidate, for example
6.x-rc1. From this point on, only bug fixes are accepted into the mainline. New features must wait for the next cycle.Weekly rc releases
Linus releases a new
-rc kernel roughly once a week. A typical cycle reaches between -rc6 and -rc9 before the tree is considered stable. The primary metric is the regression list: any patch that breaks behavior that worked in a prior release is a high-priority revert candidate.Example: the 5.4 cycle
The table below shows how the 5.4 release unfolded. All dates are in 2019.| Date | Event |
|---|---|
| September 15 | 5.3 stable release |
| September 30 | 5.4-rc1, merge window closes |
| October 6 | 5.4-rc2 |
| October 13 | 5.4-rc3 |
| October 20 | 5.4-rc4 |
| October 27 | 5.4-rc5 |
| November 3 | 5.4-rc6 |
| November 10 | 5.4-rc7 |
| November 17 | 5.4-rc8 |
| November 24 | 5.4 stable release |
If you miss the merge window for a feature, the right response is almost always to wait for the next cycle. Patches that add new features during the stabilization period are received poorly by maintainers.
Long-term support kernels
Some releases are designated long-term support (LTS) kernels and receive backported fixes for several years. The selection depends entirely on whether a maintainer has the time and need to sustain that release. You can find the current list of active LTS kernels and their maintainers at kernel.org/category/releases.html.The lifecycle of a patch
Patches do not travel directly from your editor into the mainline. The journey typically looks like this:- Design — Work out requirements and approach. Doing this in the open on mailing lists saves costly redesign later.
- Early review — Post to the relevant subsystem mailing list. Developers reply with comments on major problems.
- Wider review — A subsystem maintainer accepts the patch into their tree, which feeds into the
-nexttrees. More developers see it in an integrated state, surfacing interaction bugs. - Mainline merge — During the next merge window the subsystem maintainer asks Linus to pull. Linus trusts the chain of maintainers and merges the tree.
- Stable backport — If the patch fixes a significant bug it may be backported to stable and LTS branches.
- Long-term maintenance — The original author is expected to respond to issues discovered after the code is in production.
How patches get into the kernel: the chain of trust
The kernel is divided into subsystems — networking, memory management, architecture support, device drivers, filesystems, and more. Each subsystem has one or more designated maintainers who are the primary gatekeepers for that code. Maintainers manage their own git trees. When the merge window opens, top-level maintainers ask Linus to pull from their trees. Linus trusts subsystem maintainers not to send bad patches upstream. Subsystem maintainers, in turn, pull from lower-level trees maintained by driver or sub-subsystem authors. This chain can be two or three links long and is known as the chain of trust.Finding the right maintainer
TheMAINTAINERS file in the root of the kernel source tree maps every file and subsystem to its responsible maintainer, mailing list, and git tree. Use the scripts/get_maintainer.pl script to find the correct recipients for a given patch automatically:
Next trees and linux-next
Before patches land in Linus’s tree they pass through staging areas:linux-next
linux-next
The primary integration tree for next-cycle patches, maintained by Mark Brown. All patches destined for the next merge window should appear in linux-next before the window opens. You can download it from:New snapshots are announced on the
linux-kernel and linux-next mailing lists.The -mm tree
The -mm tree
Andrew Morton’s integration tree, sometimes called
mmotm (mm of the moment). It collects patches that do not yet have a designated subsystem tree, along with debugging helpers. Around 5–10% of mainline patches arrive via -mm. Use it for testing but do not expect it to always compile cleanly.Staging tree (drivers/staging/)
Staging tree (drivers/staging/)
Greg Kroah-Hartman maintains the staging tree for drivers and filesystems that are not yet ready for mainline quality standards. Each staging driver has its own subdirectory containing a
TODO file that lists what must be done before the driver can graduate to the main tree. Staged drivers must at minimum compile correctly.Mailing lists
Most kernel development communication happens on mailing lists hosted at subspace.kernel.org. The central list islinux-kernel@vger.kernel.org, but most subsystem work happens on dedicated lists — for example netdev@vger.kernel.org for networking. Always check the MAINTAINERS file for the right list before posting.
Tools
The dominant version control system in kernel development is git. Familiarity with git is a practical requirement — at minimum you need it to track what the mainline and other subsystem trees are doing.git
The primary SCM used by virtually all kernel maintainers.
Mercurial
An alternative used by some developers who prefer its interface.
Quilt
A patch management system oriented toward tracking a set of changes against an evolving codebase. Used by some maintainers for managing queues of upstream-bound patches.
b4
A tool that automates many technical aspects of patch submission, including dependency tracking, running checkpatch, and sending mail.