b4: The Tool That Modernized Kernel Development's Email Patch Workflow

In March 2020, kernel.org infrastructure administrator Konstantin Ryabitsev introduced b4 as tooling around the Linux kernel’s mailing-list and lore.kernel.org workflow. It did not replace email review with a forge. It made public-inbox threads, patch-series reconstruction, trailers and provenance easier to consume reproducibly.

Its significance lies in strengthening an existing distributed protocol rather than imposing a new central review database.

Kernel patches were already structured email

Kernel contributors typically generate patches with Git, send plain-text series to maintainers/lists, receive inline replies, revise versions and route accepted work through subsystem trees. Message-IDs link public discussion; Signed-off-by, review/test trailers and cover letters carry process metadata.

This workflow scales without requiring every participant to hold an account on one forge, but raw mail clients/archives make it tedious to find every patch/revision/reply and prepare a clean mailbox for application.

lore.kernel.org made mail addressable

lore uses public-inbox to archive kernel-related mailing lists. A stable Message-ID URL can identify a cover letter, patch or reply; threads remain searchable and downloadable. b4 uses that archive/protocol so a maintainer can start from a Message-ID instead of manually saving messages from a mail client.

The archive is public evidence, not a trust oracle. Message content still needs review, identity/provenance assessment and testing.

`b4 am` reconstructed a reviewable series

The early core operation accepted a Message-ID, retrieved the thread, selected/reconstructed the patch series and prepared an mbox suitable for inspection/application. It could collect follow-up trailers such as Reviewed-by from replies while checking that they corresponded to the relevant patch revision.

That reduced clerical failure: wrong version, missing patch, broken thread order or manually copied trailers. It did not decide that a review trailer was deserved or that code was correct.

Applying remains a separate trust boundary

A safe maintainer workflow fetches into a clean repository/worktree, examines b4 output, verifies base/revision, reads every diff and trailer, checks signatures/attestation policy, applies to a throwaway branch, builds/tests, then compares the resulting commit.

Do not pipe a Message-ID from an untrusted chat directly into a privileged source tree. Git patches can modify build scripts, CI, generated files, tests and documentation; success from git am proves syntax/application, not safety.

Attestation addressed transit and identity evidence

Ryabitsev’s launch article paired b4 with cryptographic patch attestation: a way to verify that message/patch content associated with a sender had not changed in transit under the chosen attestation scheme. b4 later integrated with the kernel community’s patatt approach and email-domain/DKIM evidence where available.

Attestation is narrower than code review. A valid signature proves control of a key/domain path and content integrity under policy; it does not prove the author is authorized for a subsystem, the patch is non-malicious, or the key is uncompromised.

Trailers require semantics, not string collection

Kernel trailers include developer certificate sign-off, review, testing, reporting, acknowledgement and links. Each has meaning defined by project documentation. b4 can discover/format trailers, but maintainers must check identity, patch version and whether a reply applies to the whole series or one patch.

Never add Reviewed-by because a reviewer commented, or preserve a trailer after materially rewriting the patch without consent. Tooling should make provenance visible, not turn discussion into automatic approval.

Contributor tooling expanded the scope

b4 evolved beyond maintainer retrieval. Its contributor workflow can prepare a managed series, track revisions/cover-letter metadata, check recipients, reroll and send through the project’s email path. Current commands and configuration should be taken from the installed b4 documentation because interfaces evolved after 2020.

The workflow complements git format-patch/git send-email; it does not exempt contributors from scripts/checkpatch.pl judgment, build/static tests, get_maintainer.pl review, subsystem instructions or the Developer Certificate of Origin.

Revisions became more reproducible

Patch series often move from v1 to v2/v3 with change logs and retained review where appropriate. Managed series tooling can reduce version-number mistakes, stale cover letters and missing range diffs. Message-ID/thread links make prior discussion discoverable.

Reproducibility still requires recording base commit, branch/subsystem, b4 version/config, selected revision, applied commit IDs and test result. A reroll against a new base can change context even when the conceptual diff looks similar.

Email remains an interoperability layer

b4’s adoption showed that email need not mean manual mailbox archaeology. Public-inbox supplies an open archive/interface; Git supplies content history; b4 supplies workflow reconstruction; maintainers retain their own trees and decision rights.

Forge mirrors and CI can participate without becoming the sole source of truth. This matters for a project distributed across many organizations and subsystem policies.

Installation and updates need supply-chain discipline

b4 is published through the official kernel.org Git repository and documented site, and packages may be supplied by distributions/PyPI. Choose one trusted channel, verify package/source identity and version, isolate Python dependencies where appropriate, and review release notes before automation changes.

Do not install arbitrary similarly named packages as root or embed credentials in config/logs. Sending mail introduces SMTP credentials, signing keys and address data; protect them using the documented mail/key tooling.

Modernization without overstating replacement

b4 did not cause the kernel to begin using email, invent Message-IDs, replace git am, or centralize maintainership. It reduced repeated human work and improved provenance/series handling around a workflow already encoded in kernel process documents.

That quieter change is substantial: when a contributor/maintainer can turn a public thread into a reviewable, attestable, version-aware local series, the chance of clerical error falls while the review record remains open.

Build an auditable b4 acceptance path

For a candidate series, record source Message-ID/lore URL, fetched revision, b4 version, attestation result, trailer changes, base commit, diff/stat, generated commits, tests and maintainer decision. Test malformed/missing revisions and offline/archive failure. Confirm b4 never auto-sends or applies outside the expected repository.

The tooling succeeds when another reviewer can reproduce the same series from public evidence, distinguish transport integrity from code approval, and remove the local branch/config without affecting upstream or credentials.

Related:

Sources: