The Release Cycle: Merge Window, -rc, linux-next

A Linux kernel development cycle runs roughly 9 to 10 weeks from start to finish. It begins the moment Linus releases a new kernel (say, v6.9), immediately opens a two-week merge window, then enters a stabilization phase of roughly 7-8 weekly release candidates (-rc1, -rc2, ..., -rcN), and ends with the next final release (v6.10).

The versioning scheme is straightforward: v<major>.<minor>. As of the modern era (post-v3.0), the major number almost never changes — Linus increments the minor number every cycle. There is no fixed calendar date for a release; Linus decides when -rcN is stable enough, typically after 7 or 8 candidates. The whole process repeats indefinitely.

Think of it as a river with a flood season and a dry season. During the merge window, the floodgates open and huge volumes of new code pour in. Then the floodgates close, and the next several weeks are spent calmly letting the sediment settle — fixing bugs, not adding features. By the time the river reaches the sea (final release), it is clear.

# Check the current kernel version on a running Linux system
uname -r
# Example output: 6.9.3-arch1-1
#                 ^   ^   ^
#                 |   |   +-- distro/local patch level
#                 |   +------ stable update number
#                 +---------- kernel version (major.minor)

# On kernel.org, development is tracked like this:
# v6.9   -- released, starts v6.10 merge window
# v6.10-rc1  -- first release candidate
# v6.10-rc7  -- late stabilization
# v6.10      -- final release

The merge window is the only time new features, new subsystems, new drivers, and significant refactors can enter Linus's tree (the official torvalds/linux repository on kernel.org). It lasts approximately two weeks after the previous release.

During this window, subsystem maintainers send Linus a pull request — a Git pull request in the literal Git sense, not a GitHub PR. They send an email with a signed Git tag pointing to their subsystem tree, and Linus executes git pull to merge it. Thousands of commits can arrive in a single pull. In recent cycles, the merge window absorbs 10,000-15,000 commits.

There is a crucial prerequisite: the code being merged during the window must already be reviewed, tested, and staged in a maintainer's subsystem tree. Maintainers do not scramble to collect patches during the merge window — they have been accumulating and reviewing patches for the entire previous cycle. The merge window is just the time those already-reviewed batches flow upward to Linus.

This is a key insight: the two-week window looks like chaos from the outside, but it is actually the harvest phase of a 10-week growing season. The real work happened earlier.

# What a maintainer's pull request email looks like (simplified):
# From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
# To: Linus Torvalds <torvalds@linux-foundation.org>
# Subject: [GIT PULL] driver core changes for v6.10-rc1
#
# The following changes since commit abc123...:
#
# Please pull the following Linus git tree:
#
#   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
#   tags/driver-core-6.10-rc1
#
# Shortlog:
#   ...(list of commits)...

# Linus runs something like:
git pull \
  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git \
  tags/driver-core-6.10-rc1

Once Linus closes the merge window (usually by issuing -rc1 and sending an email declaring it closed), the kernel enters stabilization mode. No new features. Only bug fixes, regression fixes, and documentation improvements.

Each Sunday (roughly), Linus releases a new release candidate snapshot: -rc1, -rc2, ..., typically up to -rc7 or -rc8. Each -rc is a real, bootable kernel. Testers worldwide download and run these kernels on diverse hardware, and bug reports flow back to maintainers and Linus via the mailing lists.

-rc1 is the roughest. It contains all the newly merged code and often has regressions — bugs in code that used to work but broke due to new changes. These are treated with extreme urgency; Linus is famously vocal about regressions and his policy is clear: a regression is always a bug.

-rc4 to -rc6 is typically where things stabilize. Patch volume drops sharply. Only high-confidence fixes make it in.

-rc7 or -rc8 is essentially a release rehearsal. If no critical bugs appear, Linus declares it final.

The release candidate phase is where you as a tester can contribute enormously, even before writing code. Running linux-next or -rc kernels and reporting bugs (with git bisect to pinpoint the offending commit) is valued work.

# Fetch and build an -rc kernel from kernel.org
# (assumes you have build dependencies installed)

# 1. Clone the mainline tree (shallow for speed)
git clone --depth=1 \
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git \
  linux-mainline
cd linux-mainline

# 2. Check out a release candidate tag
git fetch --tags
git checkout v6.10-rc5

# 3. Use your running kernel's config as a base
cp /boot/config-$(uname -r) .config
make olddefconfig   # accept defaults for new options

# 4. Build (use all cores)
make -j$(nproc)

# 5. Install (distro-specific; here: Debian/Ubuntu style)
sudo make modules_install
sudo make install

Linus does not review individual patches. That would be physically impossible — there are thousands of patches per cycle. Instead, the kernel is divided into subsystems, each maintained by one or two trusted maintainers who do review patches in their area.

Examples:

• Greg Kroah-Hartman maintains the USB subsystem, driver core, staging, tty, and more
• David S. Miller (and Jakub Kicinski) maintain the networking stack
• Tejun Heo maintains cgroups and block I/O
• Thomas Gleixner maintains x86 arch code, timers, and IRQ subsystems

Each maintainer has a public Git tree on kernel.org (or elsewhere). Their workflow is:

1. Receive patches on the relevant mailing list (e.g., linux-usb@vger.kernel.org)
2. Review, request changes, re-review
3. Apply to their subsystem tree (often with git am from an mbox)
4. During the merge window, send a pull request to Linus

Where are these trees listed? In MAINTAINERS — a file in the kernel source that maps every file, directory, and subsystem to its maintainer, mailing list, and Git tree URL. This file is your map.

# Find the maintainer for a specific file in the kernel source
# The kernel ships a helper script for this
cd linux-mainline

# Who maintains the USB HID driver?
scripts/get_maintainer.pl drivers/hid/usbhid/usbmouse.c
# Output might look like:
# Jiri Kosina <jkosina@suse.cz> (maintainer:HID CORE LAYER)
# Benjamin Tissoires <benjamin.tissoires@redhat.com> (maintainer)
# linux-input@vger.kernel.org (open list:HID CORE LAYER)
# linux-kernel@vger.kernel.org (open list)

# Look up the MAINTAINERS entry directly
grep -A 10 '^NETWORKING \[IPv4/IPv6\]' MAINTAINERS
# Shows: maintainer names, mailing list, git tree URL, files covered

# Check what tree a subsystem uses
grep -A 5 'F:\s*net/' MAINTAINERS | grep '^T:'

Here is the problem: suppose the networking maintainer and the filesystems maintainer both accept patches that independently look fine, but together they break the build or cause a runtime bug. Nobody would know until they landed in Linus's tree during the merge window, which is exactly the wrong time to find out.

The solution is linux-next, maintained by Stephen Rothwell. Every day (on working days), Stephen pulls the 'next' branch of approximately 200+ subsystem trees into a single integration tree and publishes it. If the combined tree fails to build or boot, he notifies the relevant maintainer.

linux-next is the early warning system for the kernel. It is always the tip of what will enter the next merge window. Developers testing on linux-next catch cross-subsystem conflicts weeks before they would be a problem.

Important: linux-next is not a stable tree. It resets constantly. You should not run it on a machine you depend on. But for kernel developers and serious testers, it is invaluable.

As a contributor, having your patch land in a subsystem's 'next' branch means it is in linux-next and will likely enter the next merge window. That is a strong signal your patch has been accepted.

# Clone linux-next
git clone \
  https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
cd linux-next

# linux-next is tagged daily: next-YYYYMMDD
git tag -l 'next-*' | tail -5
# next-20240610
# next-20240611
# next-20240612
# next-20240613
# next-20240614

# Check out the latest daily snapshot
git checkout next-20240614

# To keep it updated (Stephen rebases and re-tags daily)
git fetch origin
git checkout next-$(date +%Y%m%d)  # today's snapshot

When Linus releases v6.10, his job with that version is done. He moves on to v6.11. But the rest of the world — embedded devices, server distros, Android, long-lived appliances — cannot upgrade every 10 weeks. They need bug fixes and security patches backported to the version they ship.

This is the job of the stable tree, maintained by Greg Kroah-Hartman and Sasha Levin at stable/linux-stable. The rules for what gets backported are strict (documented in Documentation/process/stable-kernel-rules.rst):

1. The fix must already be in Linus's mainline tree
2. It must fix a real bug (no features, no cleanups)
3. It must be small and clearly correct
4. It must not introduce new regressions

Versions get stable updates: v6.10.1, v6.10.2, etc., until the next release makes them irrelevant (usually 2-4 months).

LTS (Long Term Support) kernels are special stable kernels maintained for 2-6 years. LTS kernels are announced at kernel.org and are chosen because they coincide with major Android releases or important enterprise cycles. Recent LTS versions include 6.6, 6.1, 5.15, 5.10, 5.4, and 4.19.

A patch can carry a Cc: stable@vger.kernel.org tag to request backporting, or a maintainer can submit it manually. The stable team reviews all candidates.

# A commit that requests stable backporting looks like this in its commit message:

# commit abc123def456...
# Author: Jane Developer <jane@example.com>
# Date:   Mon Jun 10 12:00:00 2024
#
#     net: fix null pointer dereference in tcp_recvmsg
#
#     When the socket is closed while a recv is in progress,
#     sk->sk_receive_queue is accessed after being invalidated.
#     Add a NULL check before dereferencing.
#
#     Fixes: deadbeef1234 ("net: tcp: rework recvmsg path")
#     Cc: stable@vger.kernel.org  # 6.6+
#     Signed-off-by: Jane Developer <jane@example.com>
#     Reviewed-by: Senior Maintainer <sm@kernel.org>

# The 'Fixes:' tag identifies the commit that introduced the bug
# The 'Cc: stable' tag requests backporting to stable trees >= 6.6

Let's trace the complete lifecycle of a real patch from author's keyboard to Linus's tree.

Week 0 (anytime during the cycle): You write a fix for a USB driver bug. You run scripts/get_maintainer.pl to find the USB maintainer and mailing list. You format your patch with git format-patch and send it with git send-email.

Week 1-3: The maintainer and community review your patch on the mailing list. You receive feedback (Reviewed-by, Tested-by, or requests for changes). You incorporate changes, resend as v2, v3...

Week 4-8 (still in the current cycle): The maintainer applies your patch to their subsystem's 'next' branch. It appears in linux-next within a day. Testing continues at scale.

End of cycle (Linus releases v6.X): The merge window opens. The USB maintainer sends a pull request to Linus containing your patch (along with hundreds of others). Linus pulls it.

Day 3 of merge window: Your patch is in torvalds/linux. -rc1 a couple weeks later will contain it.

~10 weeks after merge window: v6.(X+1) is released, containing your fix. If you tagged it Cc: stable, the stable team may backport it within days.

Total elapsed time from first send to final release: 2-5 months, depending on where in the cycle you started.

# The patch submission workflow in shell commands

# 1. Create a branch for your work
git checkout -b fix/usb-null-deref v6.10-rc5

# 2. Make your fix, commit it with a proper message
git add drivers/usb/core/message.c
git commit -s  # -s adds your Signed-off-by automatically

# 3. Format it as a patch file
git format-patch -1 HEAD --subject-prefix='PATCH'
# Creates: 0001-usb-core-fix-null-pointer-in-usb_submit_urb.patch

# 4. Check it passes basic style/correctness tests
scripts/checkpatch.pl 0001-usb-core-fix-null-pointer-in-usb_submit_urb.patch

# 5. Find who to send it to
scripts/get_maintainer.pl \
  0001-usb-core-fix-null-pointer-in-usb_submit_urb.patch

# 6. Send it via email
git send-email \
  --to='Greg Kroah-Hartman <gregkh@linuxfoundation.org>' \
  --cc='linux-usb@vger.kernel.org' \
  --cc='linux-kernel@vger.kernel.org' \
  0001-usb-core-fix-null-pointer-in-usb_submit_urb.patch

The MAINTAINERS file at the root of the kernel source is 20,000+ lines and maps the entire kernel to its human stewards. Every patch must be sent to the right people; sending to the wrong list causes delays or silence.

Each entry has fields:

• M: — Maintainer name/email
• R: — Reviewer (not full maintainer but should be CC'd)
• L: — Mailing list
• T: — Git tree (type + URL)
• S: — Status (Maintained, Odd Fixes, Orphan, Obsolete...)
• F: — Files/patterns this entry covers
• K: — Keyword regex to match commit messages

The get_maintainer.pl script parses this file automatically. Always use it — do not guess. A patch sent to the wrong list may be politely redirected, but it wastes everyone's time.

If the status is Orphan or Obsolete, the subsystem has no active maintainer, which changes how you contribute (patches go directly to Linus or a staging tree).

# Example MAINTAINERS entry (from actual kernel source, simplified)
#
# USB SUBSYSTEM
# M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
# L: linux-usb@vger.kernel.org
# S: Supported
# T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
# F: Documentation/driver-api/usb/
# F: drivers/usb/
# F: include/linux/usb.h
# F: include/linux/usb/

# Find all entries covering a given file:
scripts/get_maintainer.pl --file drivers/usb/core/hub.c

# List all SUPPORTED subsystems (not orphaned)
grep -B5 'S:\s*Supported' MAINTAINERS | grep '^M:' | wc -l

# Check the git tree for the arm64 architecture
grep -A 15 '^ARM64 ARCHITECTURE' MAINTAINERS | grep '^T:'

Linux kernel commits carry a rich set of structured tags in the commit message body. These are not decoration — they are a legally significant chain of accountability and a machine-parseable workflow record.

Signed-off-by: (mandatory) — By adding this line with git commit -s, you certify under the Developer's Certificate of Origin (DCO) that you have the right to submit this code, that it is your original work or properly licensed, and that you understand it will be incorporated under the kernel's license (GPL-2.0). Every person who handles the patch (author, co-author, maintainer) adds their own Signed-off-by.

Reviewed-by: — A named person has read the patch and believes it is correct. Adds credibility; multiple reviewers make acceptance faster.

Tested-by: — A named person has tested the patch and it worked. Hardware-specific patches especially benefit from this.

Acked-by: — The maintainer of affected code agrees with the approach, but isn't the primary reviewer.

Fixes: — Points to the commit that introduced the bug being fixed. Format: Fixes: <12-char-hash> ("commit subject"). This is critical for stable backporting — the stable team uses it to identify which kernels need the fix.

Cc: stable@vger.kernel.org — Request backport to stable trees. Can include version range like # 5.15+.

# A complete, well-tagged kernel commit message:

# net: ipv4: fix use-after-free in ip_options_compile
#
# When ip_options_compile() encounters an error partway through
# parsing, it calls kfree() on an allocated buffer but then
# continues to dereference the pointer. Move the error path to
# skip the dereference.
#
# This was introduced by commit a1b2c3d4e5f6 which restructured
# the error handling path without noticing the implicit assumption
# about buffer lifetime.
#
# Fixes: a1b2c3d4e5f6 ("net: ipv4: restructure options parsing")
# Cc: stable@vger.kernel.org  # 5.15+
# Cc: networking@vger.kernel.org
# Reported-by: Fuzzer Bot <bot@example.com>
# Signed-off-by: Jane Developer <jane@example.com>
# Reviewed-by: Senior Netdev <sr@kernel.org>
# Tested-by: Jane Developer <jane@example.com>
# Signed-off-by: David S. Miller <davem@davemloft.net>

Understanding when to send a patch is as important as the patch itself. The kernel community has strong norms about timing.

Best time to send: Immediately after a new release (v6.X.0 is out), when the merge window is opening. Your patch has an entire cycle to be reviewed and staged in a maintainer's tree.

Worst time to send: During or just after the merge window. Maintainers are overwhelmed pulling trees and doing merges. Your patch will be missed or explicitly deferred.

For bug fixes: Bug fixes (especially regressions) can be sent at any time and will be expedited regardless of cycle phase. Regressions during -rc phase are the highest priority.

For new features: Features must be staged in a subsystem tree before the merge window opens. If your feature misses staging by even a day, it waits a full cycle.

Watch the mailing list tone: Around -rc6/-rc7, Linus starts posting "I'm almost done, expecting to release next week." That is your signal that the merge window is imminent.

A practical rule: if you are new, aim to have your patch reviewed and in a maintainer's 'next' branch by -rc4 of the current cycle. That gives it the whole rest of the cycle to bake in linux-next before the merge window.

# Monitor the kernel mailing list for cycle announcements
# Linus posts release announcements to lkml and oss-security

# Subscribe to the Linux Kernel Mailing List digest:
# https://subspace.kernel.org/vger.kernel.org.html
# Or browse via: https://lore.kernel.org/lkml/

# Check the current kernel release status:
curl -s https://www.kernel.org/ | grep -E 'stable|mainline|longterm' | head -20

# Or use the kernel.org JSON API:
curl -s https://www.kernel.org/releases.json | \
  python3 -c "
import json,sys
data=json.load(sys.stdin)
for r in data['releases'][:5]:
    print(r['moniker'], r['version'], r['released']['isodate'])
"

One of the most valuable things a kernel tester can do is identify which specific commit introduced a regression. This transforms a vague bug report into an actionable, pinpointed fix request. The tool for this is git bisect.

The idea is binary search through commit history. You tell Git: "version X was good, version Y is broken." Git checks out the commit exactly halfway between them and asks: good or bad? You test, answer, and Git narrows it down. After log₂(N) steps, you have the exact offending commit.

For kernel bisecting, each step requires: building the kernel, installing it, rebooting, testing the bug, and reporting back. It is slow (30-60 minutes per step) but incredibly powerful. A typical bisect through 10,000 commits takes only 13-14 steps.

Proper bug reports to the mailing list always include: kernel version where it broke, last known good version, hardware info (lspci -v, dmesg), and ideally a git bisect result naming the offending commit.

# Full git bisect workflow for a kernel regression
# Suppose 6.9 works, 6.10-rc3 does not

cd linux-mainline
git bisect start

# Mark the broken state
git bisect bad v6.10-rc3

# Mark the last known good state  
git bisect good v6.9

# Git checks out the midpoint commit and prints:
# Bisecting: 7500 revisions left to test after this
# [abc123] some commit in the middle

# Now: build and test
make -j$(nproc) && sudo make modules_install && sudo make install
# reboot into the new kernel, test the bug

# If the bug is present:
git bisect bad
# If the bug is absent:
git bisect good

# Repeat until Git prints:
# abc123def is the first bad commit
# commit abc123def
# Author: ...

# Finish and return to original HEAD
git bisect reset

# For automated bisect (if you have a test script that exits 0=good, 1=bad):
git bisect run ./test_my_bug.sh

Linus Torvalds is the creator of Linux and its Benevolent Dictator for Life (BDFL). He has final say on what enters his tree. But as the kernel has grown, his role has evolved from hands-on reviewer to orchestrator and quality arbiter.

Linus reviews the pull requests from maintainers. He does not usually review individual commits. If a pull request contains bad code, he pushes back on the maintainer, who is responsible for what they submitted. This creates a strong accountability chain: maintainers know their reputation depends on sending Linus clean, well-reviewed work.

Linus is famous for blunt, sometimes harsh feedback when standards are not met — particularly around security, regression, or API stability. His emails are archived on lkml and are worth reading to understand what the kernel community values. Some famous examples: his rejection of C++ in the kernel ("C++ is a horrible language"), his insistence that regressions are always bugs, and his periodic architectural rejections of entire subsystem approaches.

That said, the kernel's success is partly because of this centralized quality gate. The decentralized maintainer network handles scale; Linus handles coherence. New contributors almost never interact with Linus directly — your world is the subsystem maintainer and the mailing list.

# You can read Linus's public commit messages and pull request responses
# directly in the git log of torvalds/linux:

# Browse merge commits (which are Linus's pull responses)
git log --merges --oneline --author='Linus Torvalds' v6.9..v6.10-rc1 | head -20

# A typical merge commit from Linus looks like:
# Merge tag 'usb-6.10-rc1' of git://git.kernel.org/...
# Merge tag 'net-6.10-rc1' of git://git.kernel.org/...
# Merge tag 'arm64-6.10' of git://git.kernel.org/...

# The merge commit message often contains Linus's commentary on
# the pull request, written in a conversational, sometimes irreverent style
git show --stat $(git log --merges --oneline -1 v6.10-rc1 | cut -d' ' -f1)