Linus Torvalds has fired a sharp warning at kernel contributors: stop stuffing patch emails with automated “Link:” lines that point to nothing new. In a blunt exchange on the Linux Kernel Mailing List (LKML), the kernel’s creator said these boilerplate references waste reviewers’ time and bury the signal that maintainers need to make fast, correct decisions.
The gripe: redundant links, zero value
The trigger was a routine fix that included a “Link:” entry promising context. Instead, it circled back to the same patch description already under review. Torvalds’ message was simple: include a link only if it adds information not present in the commit message—crash logs, regression reports, benchmarks, or prior discussions that shaped the decision. Anything else is noise.
This is not a theoretical nitpick. Kernel maintainers rely on metadata tags—Link:, Fixes:, Reported-by:, and others—to triage patches quickly. A “Link:” that leads to a duplicate summary, a bot-generated page, or the same email thread without extra details forces reviewers to dig elsewhere or give up on the context entirely.
How automation made it worse
Modern tooling contributes to the clutter. Continuous integration bots, repository integrations, and helper scripts often auto-insert link lines during submission. These references can be helpful when they connect a patch to an external bug tracker or a prior discussion with key technical arguments. But many simply point back to the patch itself or a generic landing page with no new content.
The rise of AI-assisted workflows adds another wrinkle. Some contributors rely on templates or automated summaries that generate “Link:” fields by default. When rushed, those fields slip through unchanged, creating a veneer of completeness without the substance reviewers need.
Why it matters for kernel velocity
Every merge window sees a flood of changes—commonly in the range of ten to fifteen thousand non-merge commits, based on counts regularly cited by maintainers and community analyses. LKML itself handles a torrent of mail each day. Small inefficiencies multiply at that volume. A few seconds wasted per patch on circular links scales into hours of lost review capacity across the maintainer network.
The kernel project’s success depends on quick, confident decisions from subsystem maintainers and from Torvalds during pulls. When commit messages are crisp and the “Link:” fields genuinely expand the story—linking to a regression tracker entry, a detailed bug report, or performance data—reviewers gain the context to accept, defer, or reject with minimal back-and-forth.
What a useful “Link:” looks like
Kernel documentation on submitting patches encourages commit messages that stand on their own while referencing external sources for depth. High-value examples include:
• A link to a bug tracker entry with reproduction steps and affected versions.
• A link to the prior LKML discussion where competing approaches were weighed.
• A link to regression reports maintained by the community’s regression tracker, cataloging when a problem first appeared.
• A link to performance or correctness data (for example, results from CI systems such as KernelCI) that would bloat a commit message if pasted inline.
In each case, the link must add material not already summarized in the patch. If the commit message fully explains the issue and fix, the “Link:” can be omitted without guilt.
Keep the human in the loop
Automation should assist, not replace, editorial judgment. Before sending, contributors should scan auto-generated tags and delete anything that doesn’t pull its weight. Maintainers routinely recommend short, self-contained commit messages with essential context, plus selectively chosen references for deep dives.
This is doubly important for newcomers who follow templates to the letter. The kernel community values conventions, but it values clarity more. A lean commit with a strong rationale will always beat a verbose one padded with empty links.
A broader push for signal over noise
Torvalds has long pressed for pragmatic communication: clear subject lines, precise explanations, and metadata that helps reviewers do their job. His latest admonition fits that pattern. With a codebase of many tens of millions of lines and contributions from thousands of developers, the Linux project depends on habits that scale.
The takeaway is straightforward: if a link explains something the commit message cannot—include it. If it merely echoes what’s already there—remove it. That small act of curation respects maintainers’ time and keeps the world’s most critical open-source project moving quickly and safely.