b4: The Tool That Modernized Kernel Development's Email Patch Workflow
How kernel.org administrator Konstantin Ryabitsev's b4 tool, introduced in March 2020, made the Linux kernel's mailing-list-based patch workflow substantially less painful without abandoning email itself.
In March 2020, Konstantin Ryabitsev — the kernel.org infrastructure administrator responsible for lore.kernel.org, the public-inbox archive underlying the kernel’s mailing lists — introduced a tool called b4, aimed squarely at one of the most persistent points of friction for anyone participating in Linux kernel development: the email-based patch workflow that the project has relied on since long before GitHub-style pull requests existed as an alternative.
Why the kernel still uses email for patches at all
Unlike most modern open-source projects, the Linux kernel has never adopted a pull-request-centric workflow through a forge like GitHub or GitLab as its primary contribution mechanism. Patches are sent as plain-text emails to mailing lists, reviewed inline via email reply, and applied by maintainers using git am directly from the mailbox. This isn’t inertia so much as a deliberate fit for the kernel’s scale and structure — a deeply hierarchical maintainer tree, an enormous and highly distributed contributor base, and a review culture built around inline, line-by-line email commentary that predates and, for the kernel’s specific workflow, arguably still outperforms forge-based review UIs for their particular use case.
The actual pain point b4 addressed
None of that made the raw mechanics pleasant. Manually locating a specific patch series in a mailing list archive, correctly threading and downloading every message in the series in the right order, extracting them into a usable mbox file, and applying them cleanly with git am was a genuinely tedious, error-prone, multi-step manual process — one that grew from a smaller, earlier tool called get-lore-mbox before formally becoming its own independent project under the name b4.
What b4 actually automates
Given nothing more than a message ID from a patch series, b4 fetches the entire thread directly from lore.kernel.org’s public-inbox archive, correctly assembles it in order, and produces a ready-to-apply mbox file — collapsing what had been a manual, multi-step archive-hunting exercise into a single command. It layered on additional capabilities over subsequent releases, including cryptographic patch attestation (verifying that a patch’s content and metadata weren’t altered anywhere in transit between the original author and whoever is applying it), and, starting with version 0.10, features aimed specifically at contributors sending patches rather than just maintainers receiving them — wrapping git format-patch and git send-email with additional conveniences like automatic version-number tracking across a patch series’ revisions.
Why this was a meaningful, if quiet, shift
b4 didn’t replace the kernel’s email-based workflow with something else — it made the existing workflow’s rough edges dramatically less painful for both maintainers processing patches and contributors sending them, without requiring anyone to abandon the tooling and review culture that email-based development had built up over decades. That’s a meaningfully different kind of improvement than a wholesale workflow migration would have been, and it’s part of why b4 saw fairly rapid, broad adoption across kernel subsystems rather than facing the kind of resistance a more disruptive tooling change often does.
Where it stands now
b4 has continued evolving well past its initial 2020 introduction, maintained actively on git.kernel.org and distributed via PyPI, with Ryabitsev continuing to add capability on top of the core fetch-and-apply functionality that made it useful in the first place. It’s a clear example of meaningful workflow tooling improvement that worked with an unusual, decades-old development process rather than trying to replace it outright.
Sources: