The Kernel Community & Maintainer Hierarchy

A common misconception is that Linus reviews every patch. He does not — and by design, he cannot. The kernel receives roughly 10,000–12,000 commits per release cycle, from hundreds of contributors. Linus's actual role is integrator: he pulls entire subsystem trees from trusted lieutenants during the two-week merge window that opens after each release. He reviews the merge commits, scans for architectural problems, and occasionally dives deep into a controversial change — but the day-to-day review work is entirely delegated.

Think of it like a newspaper. The editor-in-chief (Linus) publishes a paper with dozens of sections. Each section has an editor (a lieutenant/maintainer) who is responsible for the quality of their section. The editor-in-chief does not review every article; they review the section editors' judgment. If a section editor consistently produces bad work, they are replaced. This is why Linus's occasional public criticism of a subsystem's code quality is significant: it signals trust erosion.

Linus communicates almost exclusively via the linux-kernel mailing list (LKML) and his torvalds/linux GitHub mirror (which he uses for pull requests, not issues or PRs in the GitHub sense). He makes his decisions in public, with reasoning. Even reversals are documented on-list — search the archives for 'I was wrong' and you will find them.

Practically: you will almost never interact with Linus directly as a new contributor. Your patch goes to a subsystem maintainer, not to Linus. If it is good, it eventually reaches him invisibly, carried by the subsystem tree.

Below Linus sits a layer of lieutenants — highly trusted maintainers who own major subsystems. Examples include Greg Kroah-Hartman (drivers/staging, USB, tty, char-dev), David S. Miller and Jakub Kicinski (networking), Thomas Gleixner (timers, x86), Ingo Molnar (scheduler, x86 core, locking), and Andrew Morton (mm, misc).

Each lieutenant maintains their own subsystem tree — a git repository that is a branch of the mainline kernel, plus the patches accepted for their subsystem. For example, the networking tree lives at git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git. When Linus opens the merge window, Greg pulls a 'pull request' (actually a git pull with a signed tag) and Linus executes it.

Below lieutenants are subsystem maintainers who own smaller domains: an individual driver, a filesystem, an architecture port. They may or may not have their own tree; some collect patches and forward them to their lieutenant, others maintain a tree that the lieutenant pulls.

The hierarchy is not a strict org chart — it is a web of trust accumulated over time. A person becomes a maintainer by consistently producing high-quality patches and reviews, not by being appointed. The process is documented in Documentation/process/maintainer-entry-profile.rst.

The practical implication: your patch for a Realtek WiFi driver will go to the wireless maintainers (linux-wireless@vger.kernel.org), who will forward it to the networking tree, which David Miller / Jakub Kicinski will pull into their tree, which Linus will pull at merge window. Your name in git log --oneline traces this exact path.

# List the top-level subsystem trees Linus pulls from:
curl -s https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/MAINTAINERS \
  | grep -E '^T:.*git' | head -20
# Each 'T:' line in MAINTAINERS is a tree URL — that's where patches land.

The MAINTAINERS file at the root of the kernel source is a structured plaintext database that maps every file, directory, driver, and subsystem to its owner(s), mailing list(s), and git tree. It is approximately 25,000 lines and is itself maintained under version control — changes to it are patches like any other.

Each entry follows a rigid format. Key fields:

• M: — Maintainer name and email
• R: — Reviewer (a secondary person who reviews but does not merge)
• L: — Mailing list to CC
• S: — Status: Maintained, Odd Fixes, Orphan, Obsolete
• T: — Git tree URL
• F: — File or glob pattern this entry covers
• K: — Keyword regex that triggers this entry for commit messages
• B: — Bug tracker URL
• C: — IRC channel

The S: field is diagnostic gold. Maintained means an active maintainer reviews patches promptly. Odd Fixes means it gets only critical bug fixes. Orphan means nobody owns it — you can volunteer. Obsolete means it is being removed.

When you look up a file, multiple entries may match — a specific driver entry, a broader subsystem entry, and possibly an arch entry. All of them are relevant: you need to CC all matching L: lists and M: maintainers. This is exactly what get_maintainer.pl automates.

# Example MAINTAINERS entry (from the real file, simplified):
NETWORKING [GENERAL]
M:	Jakub Kicinski <kuba@kernel.org>
M:	Paolo Abeni <pabeni@redhat.com>
L:	netdev@vger.kernel.org
S:	Maintained
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
F:	net/
F:	include/net/
F:	include/uapi/linux/net*.h

get_maintainer.pl is a Perl script in scripts/ that parses MAINTAINERS and git history to produce the exact list of people and lists to CC for a given patch or diff. It is not optional: sending a patch without running this script first is one of the most common new-contributor mistakes, and it almost guarantees your patch will be missed.

The script does several things:

1. Matches the modified files against MAINTAINERS F: patterns
2. Matches the commit message against K: keyword regexes
3. Inspects git log for the modified files to find who has reviewed/authored them recently (the 'blame' heuristic)
4. Outputs a ranked list: maintainers first, then reviewers, then list maintainers, then mailing lists

The output is suitable for pasting directly into git send-email --to / --cc arguments, or you can use git format-patch | scripts/get_maintainer.pl to annotate the patch files.

A crucial distinction: the script distinguishes between the tree for fixes (net) and the tree for new features (net-next). Bug fixes go to the 'fixes' tree (e.g., net) so they can be backported; new features go to the 'next' tree (e.g., net-next). The maintainer will reject a feature patch sent to the wrong tree.

# After making your changes, generate patches and check who to send to:
cd linux/
git format-patch -1 HEAD -o /tmp/patches/

# Run get_maintainer on your patch:
perl scripts/get_maintainer.pl /tmp/patches/0001-your-change.patch

# Example output:
# Jakub Kicinski <kuba@kernel.org> (maintainer:NETWORKING [GENERAL])
# Paolo Abeni <pabeni@redhat.com> (maintainer:NETWORKING [GENERAL])
# netdev@vger.kernel.org (open list:NETWORKING [GENERAL])
# linux-kernel@vger.kernel.org (open list)

# Then send (requires git send-email configured):
git send-email \
  --to netdev@vger.kernel.org \
  --cc kuba@kernel.org \
  --cc pabeni@redhat.com \
  /tmp/patches/0001-your-change.patch

The kernel follows a ~10-week release cycle that is completely predictable and governs when your patch can land. Understanding it prevents frustration.

Week 0 — Release + Merge Window Opens: Linus releases v6.N and immediately opens a 2-week merge window. During these two weeks, lieutenants send pull requests for new features. Linus pulls frantically — sometimes 1,000 commits per day.

Week 2 — Merge Window Closes, rc1 Tags: Linus closes the merge window and tags v6.(N+1)-rc1. From now on, only bug fixes are accepted into the mainline tree.

Weeks 3–9 — rc2 through rc7/rc8: Weekly release candidates. Only fixes, regressions, and security patches. Your feature patch will be rejected with "please rebase onto net-next and resubmit after the merge window."

Week 10 — Final Release: v6.(N+1) ships. The window opens again.

For your patch: if it's a bug fix, it can go in anytime — the maintainer will apply it to the fixes tree and it may be pulled before the next -rc or even backported to stable. If it's a new feature or cleanup, it must queue in the subsystem's -next tree (e.g., net-next) and will only reach Linus in the next merge window.

The linux-next tree (maintained by Stephen Rothwell) is a daily integration tree that merges all subsystem -next trees. Running linux-next is the best way to test that your changes do not conflict with other in-flight work. Check it at git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git.

# Track the current rc cycle:
curl -s https://www.kernel.org/ | grep -E 'stable|mainline|longterm' | head -5

# Clone linux-next for integration testing:
git clone --depth=1 \
  https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git \
  linux-next

The Linux kernel does not use GitHub pull requests, Gerrit, Jira, or any web-based code review tool (though there are unofficial mirrors). All patch submission, review, and discussion happen on public mailing lists hosted on vger.kernel.org and a few others.

Key lists:

• linux-kernel@vger.kernel.org (LKML) — the catch-all list; extremely high volume (~500 emails/day); most patches are NOT sent here first
• netdev@vger.kernel.org — networking
• linux-mm@kvack.org — memory management
• linux-fsdevel@vger.kernel.org — filesystems
• Dozens of driver-specific lists

Mailing list culture norms — violating these marks you as a newcomer and can get your patch ignored:

1. Plain text only. HTML email is actively rejected by some maintainers. Configure your client to send plain text (git send-email does this correctly).
2. Inline replies, not top-posting. Quote the relevant context, reply below it. Top-posting (replying above the quoted text) is considered rude.
3. No attachments for patches. Patches are inline text, not .patch attachments (exception: git send-email sends them as inline MIME, which is fine).
4. Public review. All feedback, including harsh feedback, is public. This is intentional: it creates institutional memory. A reviewer explaining why a pattern is wrong once benefits everyone who searches the archives later.
5. Terse is not hostile. Kernel maintainers write short, direct emails. 'Applied, thanks' is high praise. 'This is wrong because X' is normal review, not an attack.
6. Subject line format. [PATCH vN subsystem/component] Short imperative description. Example: [PATCH v2 net/ipv4] tcp: fix RST handling during TIME_WAIT.
7. Cover letters for series. A patch series (multiple related patches) gets a [PATCH 0/N] cover letter explaining the big picture, followed by [PATCH 1/N], [PATCH 2/N], etc.

You can read LKML archives at lore.kernel.org — a beautifully indexed public-inbox instance that is now the canonical archive.

# Correct subject line and format for a single patch:
# Subject: [PATCH] net: fix null-ptr-deref in nf_tables_commit
#
# Commit message body — explain WHY, not just WHAT:
# When the transaction list is empty and we receive a concurrent
# netlink flush, nf_tables_commit() dereferences a stale pointer
# obtained from list_first_entry() without checking for empty.
# This was introduced in commit abc1234 ("nf_tables: batch commits").
#
# Fix it by checking list_empty() before dereferencing.
#
# Fixes: abc1234d5678 ("nf_tables: batch commits")
# Reported-by: Syzkaller <syzkaller@googlegroups.com>
# Signed-off-by: Your Name <your@email.com>

# Then the diff follows immediately after the --- marker.

A kernel commit message is a structured document, not a Git commit message in the typical open-source sense. Each field is meaningful and often machine-parsed.

Structure:

subsystem: component: short imperative summary (<=72 chars)

Problem description: what was wrong and why it was wrong.
Include any relevant context (which hardware, which workload,
which kernel version introduced it).

Solution description: what the patch does and WHY this approach
was chosen over alternatives.

Tag block (at the bottom, no blank line between tags):

Key tags:

• Signed-off-by: Name <email> — mandatory. By adding this, you certify the Developer Certificate of Origin (DCO): you wrote this code, you have the right to submit it, and you agree it can be distributed under the kernel's license. This is a legal declaration. Every person who touches the patch (author, co-authors, maintainers who forward it) adds their own Signed-off-by.
• Reviewed-by: Name <email> — a reviewer vouches for correctness
• Acked-by: Name <email> — a maintainer of related code acknowledges the change
• Tested-by: Name <email> — someone confirmed it works on real hardware
• Reported-by: Name <email> — credits the bug reporter
• Fixes: <12-char-hash> ("commit summary") — links to the commit that introduced the bug; enables automatic backporting to stable
• Link: https://lore.kernel.org/... — links to the mailing-list thread

The Fixes: tag is especially important for bug fixes: the stable maintainers (Greg KH's team) scan for this tag to identify patches that should be backported to linux-stable (the Long-Term Support trees).

# Viewing the full tag anatomy of a real kernel commit:
git log --format=fuller \
  v6.8..v6.9 \
  -- drivers/net/ethernet/intel/igc/ \
  | head -60

# To check your own commit message before sending:
git log -1 --format='%B' HEAD

# Verify DCO compliance (all authors signed off):
perl scripts/checkpatch.pl --strict 0001-your-patch.patch

scripts/checkpatch.pl is the kernel's automated style checker. Run it before every submission — maintainers will often bounce a patch with nothing but 'checkpatch errors' as feedback, which wastes everyone's time.

The kernel uses its own C style, documented in Documentation/process/coding-style.rst. Key points:

• Tabs for indentation (not spaces). Tab width is 8 columns — yes, 8, not 4. This is intentional: deep nesting becomes visually painful, which discourages it.
• 80-character line limit (soft; 100 is acceptable for readability in some cases, never exceed 100)
• K&R brace style with Linux modifications: opening braces on same line for non-function blocks, on new line for function definitions
• No trailing whitespace
• /* */ comments (not // for multi-line, though // is now accepted in many subsystems)
• EXPORT_SYMBOL vs EXPORT_SYMBOL_GPL — new interfaces should prefer _GPL

checkpatch.pl checks all of this plus many semantic patterns (usage of deprecated APIs, missing __user annotations, etc.). Run it with --strict for a more thorough check. It is not infallible — it has false positives — but a clean checkpatch output is a prerequisite, not a guarantee of acceptance.

# Run checkpatch on your staged diff:
git diff HEAD~1 | perl scripts/checkpatch.pl -

# Or on a formatted patch file:
perl scripts/checkpatch.pl --strict 0001-my-patch.patch

# Example output you want to see:
# total: 0 errors, 0 warnings, 0 checks, 42 lines checked
# 0001-my-patch.patch has no obvious style problems and is ready for submission.

# Example of a common error (tab vs spaces):
# ERROR: code indent should use tabs where possible
# +    int x = 0;  /* spaces used instead of tab */

In 2018, the Linux kernel adopted a Code of Conduct based on the Contributor Covenant. This was contentious — the kernel community had a reputation for brutal review culture, and some feared the CoC would compromise technical standards. In practice, the two concerns were separate from the start.

The CoC is enforced by the Code of Conduct Committee (a group of respected community members and kernel developers). It covers behavior at kernel events, on mailing lists, and in any kernel-related forum. The key behavioral norm it encodes is already the implicit norm of good maintainers: critique the code, not the person.

The TAB (Technical Advisory Board) of the Linux Foundation provides oversight. Reports can be made to conduct@kernel.org. The CoC does not override technical review — a patch can still be rejected firmly for being wrong. What it prohibits is personal attacks, harassment, and discriminatory behavior.

For a new contributor, the practical implication is: if a review feels like a personal attack rather than a technical critique, you have recourse. But the vast majority of even terse, critical reviews are entirely within norms — "this is wrong because of X" is not a CoC violation, it is good engineering feedback.

The CoC document lives at Documentation/process/code-of-conduct.rst in the kernel tree.

Not all users run the latest kernel. Android phones, embedded systems, and enterprise servers often run a Long-Term Support (LTS) kernel — a specific version (e.g., 6.6, 6.1, 5.15) that receives only bug and security fixes for several years.

Greg Kroah-Hartman (GKH) and Sasha Levin maintain the stable tree (linux-stable). After your bug-fix patch is merged into Linus's mainline, the stable team scans it for Fixes: tags and automatically proposes backports to affected stable branches. If your patch touches a path that affects stable but lacks a Fixes: tag, add Cc: stable@vger.kernel.org to the commit message to flag it manually.

Important rules for stable:

1. The patch must already be in mainline (or be so obviously correct that the stable team accepts a direct submission — rare)
2. It must fix a real bug (regressions, security issues, data corruption)
3. It must be small and self-contained — large refactors are not backportable
4. It must not change ABI

The LTS schedule is published at kernel.org. As of 2024-2026, LTS kernels include 6.6, 6.1, 5.15, 5.10, 5.4, 4.19 — each supported for at least 2 years, some up to 6 years.

# Check which stable trees your fix should go to.
# The Fixes: tag format:
# Fixes: abc1234defgh ("subsystem: short description of buggy commit")
#
# The hash must be exactly 12 characters.
# Script to get correct hash length:
git log --oneline --abbrev=12 HEAD~5..HEAD

# To explicitly request stable backport in your commit:
# (add this as a tag in the commit message, not in the code)
# Cc: stable@vger.kernel.org # v5.15+

lore.kernel.org is the canonical, permanent, indexed archive of all kernel mailing lists. It uses public-inbox software, which means:

1. Every email has a permanent URL of the form https://lore.kernel.org/netdev/<message-id>/
2. You can clone any list as a git repo: git clone https://lore.kernel.org/netdev/ netdev-archive --depth=1
3. Patch series are threaded: you can see the original submission, all review comments, and the final version in one thread
4. It is indexed by Sphinx/Xapian for full-text search

As a new contributor, lore.kernel.org is your primary research tool. Before submitting a patch to fix something, search lore to see if someone already posted a fix for it. Before using an API in a novel way, search to see how it is typically used in patches. Before asking a question on the mailing list, search to see if it has been answered.

The b4 tool (by Konstantin Ryabitsev) integrates with lore to make pulling and applying patch series trivial:

b4 am https://lore.kernel.org/netdev/<message-id>/

This downloads the patch series, applies it to your tree, and preserves all the review tags. Many maintainers use b4 as their primary workflow for applying reviewed patches.

# Install b4 (the lore/mailing-list workflow tool):
pip install b4

# Apply a patch series from lore directly to your kernel tree:
b4 am https://lore.kernel.org/netdev/20240101120000.12345-1-author@example.com/

# Search lore for patches touching a file (via lei, lore email interface):
b4 lei query 'dfrom:maintainer@kernel.org f:drivers/net/ethernet/intel/'

The practical question for a new contributor is: 'Where do I actually start?' The kernel is vast and every interesting subsystem seems to already have expert maintainers. The answer is that entry points are everywhere if you know where to look.

Staged drivers (drivers/staging/): Greg KH maintains a staging tree for out-of-tree drivers being cleaned up for mainline. Many have TODO files listing specific cleanup tasks. These are explicitly designed for first contributions — the bar is lower, Greg is patient with new contributors, and the path to mainline is clear. Look for 'TODO' files and checkpatch warnings.

Kernel Janitors: A loose group focused on cleanup patches — fixing checkpatch warnings, converting deprecated APIs, removing dead code. kernelnewbies.org/KernelJanitors lists current tasks.

Documentation fixes: Documentation/ patches are reviewed more leniently and help you learn the patch submission process without touching live code.

Bug fixes from syzkaller/syzbot: syzkaller.appspot.com continuously fuzzes the kernel and reports crashes. Many bugs have reproducers but no fixes yet. Finding one, understanding it, and writing a fix is a high-value contribution that maintainers actively appreciate.

The key insight: your first patch should be small and obviously correct. A one-line fix to a real bug is infinitely more valuable than a 500-line refactor that nobody asked for. Build trust and understanding incrementally.

# Find staging drivers with TODO lists:
find drivers/staging/ -name 'TODO' -exec echo {} \; -exec cat {} \;

# Find checkpatch warnings in staging (good first fixes):
for f in $(find drivers/staging/ -name '*.c' | head -20); do
  perl scripts/checkpatch.pl --no-tree -f "$f" 2>/dev/null \
    | grep -E '^(ERROR|WARNING)' | head -3 && echo "  in $f"
done