Stop fighting with broken patch applications and email formatting; here is how the ‘b4’ tool streamlines kernel-style code reviews and saves your sanity.

Taming the Mailing List Beast: Why ‘b4’ is the Review Tool You Need

I still wake up in a cold sweat thinking about the “Great Patch Debacle of 2019” on prod-kernel-build-01. I was a mid-level engineer then, trying to apply a critical 20-part patch series from the mailing list to fix a race condition in our custom driver. I spent three hours manually downloading mbox files, fighting whitespace errors because my email client decided to wrap long lines, and screaming at git am while my coffee went cold. By the time I got the code to compile, v2 of the patch series had already been posted, rendering my work obsolete.

If you work in ecosystems that rely on mailing lists—like the Linux Kernel, QEMU, or U-Boot—you know this pain. Recently, I saw a discussion brewing about b4 helping with reviews, and it triggered my “Senior Architect” reflex. I need to walk you through this because manual patch management is a burnout factory.

The “Why”: Email Clients Hate Code

The root cause isn’t your skill level; it’s the medium. Email was designed for text, not for precise, whitespace-sensitive code diffs. When a developer sends a patch series:

• Email clients mangle formatting (line wrapping is the enemy).
• Message-IDs get lost in threading views.
• Tracking dependencies between “PATCH v1” and “PATCH v2” is a mental overhead you shouldn’t be paying.

We are trying to bridge a stateless protocol (SMTP) with a strict, stateful database (Git). Without a translation layer, you are just manually parsing text files like it’s 1995.

The Fixes: From Basic to Pro

Here are the three ways I use b4 to stop the bleeding. If you aren’t using this tool yet, install it immediately via pip install b4.

1. The Quick Fix: Fetching Without the Headache

The most immediate win is simply getting the code from the ether onto your local branch without copy-pasting anything. Instead of hunting for the mbox download link, you just need the Message-ID from the cover letter.

I use this daily on dev-workstation-alpha to pull down entire series. It handles the threading, finds the latest version automatically, and applies it to a clean branch.

# The old way: Crying over corrupt mbox files
# The Darian way:
b4 am 20231025-fix-race-condition-v3-@example.org

# Output:
# Looking up https://lore.kernel.org/r/20231025-fix-race-condition-v3-@example.org
# Grabbing thread from lore.kernel.org/all/20231025-fix-race-condition-v3-@example.org/t.mbox.gz
# ...
# Applied: drivers/net: fix race condition in handshake

Pro Tip: b4 automatically checks if a newer version of the series exists. If you try to apply v2 but v3 is out, it will warn you. That alone has saved me hours of reviewing stale code.

2. The Permanent Fix: The ‘Review’ Workflow

Fetching code is easy, but reviewing it requires tracking what you’ve looked at. This is where the brewing features of b4 really shine. Instead of just applying patches, we want to prepare a response.

When I’m wearing my Lead Architect hat, I’m not just compiling; I’m signing off. Using the --prep flag creates a perfect environment for this.

# Prepare a branch for review/editing
b4 prep -n review-fix-race 20231025-fix-race-condition-v3-@example.org

# Now you are on a branch where you can edit commits, run tests on prod-test-db-01, 
# and when you are happy, generate your Reviewed-by tags:
b4 trailers -u "Darian Vance "

This modifies the commit messages locally to add your trailers. No more typing Reviewed-by: ... manually and making typos.

3. The ‘Nuclear’ Option: Automated Thanks & Comparison

This is for the maintainers or the “lazy” geniuses among us (I count myself in the latter). Sometimes a patch series is huge, and v4 just dropped. You reviewed v3 extensively. Do you start over?

Absolutely not. I use b4 to generate a range-diff against the previous version so I only review the changes between versions.

Here is a snippet of a script I run to check diffs before I even touch the code:

#!/bin/bash
# fast-check.sh
MSGID=$1
b4 am $MSGID
# If previous version exists locally, diff against it
if git show-ref --quiet refs/heads/review-prev; then
    git range-diff review-prev...HEAD
else
    echo "Fresh meat. Time to review from scratch."
fi

It’s a bit hacky, but it beats opening two browser windows and squinting at them side-by-side.

Stop letting email clients dictate your engineering velocity. Grab b4, configure your git config, and get back to actually fixing infrastructure.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions