The Linux kernel follows a loosely time-based, rolling release model. A major kernel release happens roughly every two to three months, and a typical release contains around 13,000 changesets touching hundreds of thousands of lines of code. Understanding how this process works is a prerequisite for contributing effectively — developers who bypass or misunderstand the process tend to have a frustrating experience.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
Each development cycle begins with the merge window, which stays open for approximately two weeks. During this window, code that has been tested and staged in subsystem trees is merged into the mainline tree maintained by Linus Torvalds at a rate approaching 1,000 patches per day. At the end of the merge window, Linus closes it and releases the first release candidate, tagged-rc1. From that point, only bug fixes are accepted. The stabilization period runs for six to ten weeks, with new -rc kernels released roughly once a week. A typical cycle produces between -rc6 and -rc9 before a stable release is tagged.
Here is how the 5.4 development cycle looked in practice:
| 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 approach is to wait for the next development cycle. Trying to sneak new features in during the stabilization period will generally result in rejection.
x.y.z numbering scheme. A patch must fix a significant bug and already be merged into the mainline to qualify for a stable update. Kernels typically receive stable updates for slightly more than one development cycle past their initial release.
Some kernels are designated long-term releases and receive support for a much longer period. The current list of active long-term kernels is maintained at kernel.org/category/releases.html.
How patches get into the kernel
Linus Torvalds is the only person who merges patches into the mainline repository, yet of the 9,500+ patches in a typical release, fewer than 2% are chosen directly by him. The kernel handles this through a chain of trust built around subsystem maintainers.Patch lands in a subsystem tree
The kernel source is divided into subsystems — networking, memory management, architecture support, filesystems, and so on. Each subsystem has one or more designated maintainers who manage their own git trees. Developers send patches to the appropriate subsystem maintainer and the relevant mailing list.
Patch enters linux-next
Before the merge window opens, subsystem trees are collected into
linux-next, maintained by Mark Brown. This integration tree gives the whole community a view of what the next release will look like and surfaces conflicts early. Patches that appear in linux-next are much more likely to land in the next merge window.Merge window opens
Subsystem maintainers send pull requests to Linus. He reviews them and pulls the patches he accepts into his tree. At this point the patches become part of the mainline.
Subsystem trees and the -next tree
Each subsystem maintainer maintains their own kernel tree, typically with git. For example, the networking tree collects patches from sub-trees dedicated to device drivers, wireless, and so on before David Miller or Jakub Kicinski forwards it upstream. This chain can be two or three links long in practice. The-mm tree, maintained by Andrew Morton, collects patches that don’t have a clear subsystem home or are aimed at core memory-management work. Roughly 5–10% of each release passes through -mm.
The lifecycle of a patch
Patches go through several distinct phases before landing in the mainline:Design
Design
Requirements and approach are worked out. Doing this in the open — on the mailing list — catches design problems early and avoids expensive redesigns later.
Early review
Early review
A patch is posted to the relevant mailing list. Developers reply with comments. This phase surfaces major problems before the patch advances.
Wider review
Wider review
Once the patch is close to ready, a subsystem maintainer accepts it into their tree, where it becomes visible to a wider audience and is tested in combination with other pending changes.
Mainline merge
Mainline merge
During the merge window, the subsystem tree is pulled into Linus’s tree. Additional review may surface new issues at this stage.
Stable and long-term maintenance
Stable and long-term maintenance
If the patch fixes a significant bug, it may also be backported to stable kernels. The original author is expected to remain responsive to issues with their code long after it merges.
Mailing lists and communication
Most kernel development happens on mailing lists. The central list islinux-kernel@vger.kernel.org, but it receives hundreds of messages per day. For subsystem work, the subsystem-specific list (found in the MAINTAINERS file) is usually more effective.
A few tips for mailing list participation:
- Use interleaved (inline) replies, never top-posting.
- Preserve the
Cc:header for all participants in a thread. - Search the list archives at lore.kernel.org before asking questions.
- Ask questions on the correct list — a networking question on
linux-kernelwill usually be redirected tonetdev.
Key resources
kernel.org
Official kernel releases, stable trees, and cross-compilation tools.
lore.kernel.org
Public archive of all kernel mailing lists, searchable by thread, message ID, and author.
linux-next tree
The integration tree that previews what the next merge window will look like.
MAINTAINERS file
Canonical list of subsystem maintainers, trees, and mailing lists.