b4 v0.15.0 released

b4 v0.15.0 released

[Konstantin Ryabitsev]

Hi, all:

B4 v0.15.0 is now available! Install or upgrade using your usual mechanism.

We're recommending the use of pipx now over pip, so if you want to start from
scratch, you can use:

    pipx install b4
    # or, if you want the new shiny review tui stuff
    pipx install b4[tui]

Full release notes: https://b4.docs.kernel.org/en/latest/releases.html
Getting started guide with screencasts: https://b4.docs.kernel.org/en/latest/reviewer/getting-started.html

# b4 review — TUI-based patch review workflow (technology preview)

The headline feature in this release is "b4 review", a terminal-based
workflow for maintainers who receive, review, and accept patches from
mailing lists. It ships as a technology preview (alpha): commands,
keybindings, configuration options, and on-disk formats may change in
incompatible ways between releases.

The TUI requires the optional "tui" dependency group:

    pipx install b4[tui]

The workflow is built around a lightweight SQLite tracking database and
per-series review branches. It comprises three cooperating TUI apps:

Tracking TUI
  Browse and manage tracked series with status indicators, take
  (apply) series using merge, linear, or cherry-pick strategies,
  compare revisions with range-diff, send thank-you messages, and
  archive completed series. The app groups series by lifecycle state
  (active, new, waiting, gone) and sorts by most-recent activity.

Review TUI
  Split-pane interface with a patch list and scrollable diff viewer.
  Add inline comments and code-review trailers, preview outgoing
  emails, invoke an external AI agent for automated review assistance,
  and send review replies — all without leaving the terminal.

Patchwork TUI
  Browse outstanding series from a Patchwork server, set state and
  archived flags, and track series into the local database for review.

Highlights:

- Series tracking and lifecycle management — track series from the
  CLI (b4 review track <msgid>), from your mail client, or from
  Patchwork. Series progress through new → reviewing → replied →
  accepted → thanked states.
- Revision discovery and upgrades — b4 automatically discovers older
  and newer revisions of a tracked series using change-id and
  in-reply-to chains. Upgrading to a newer revision preserves your
  review state and prior context.
- Inline commenting — press "r" in the review view to open $EDITOR
  with the full diff quoted. Write your comments below the relevant
  lines and b4 will format them as proper email replies. The diff
  view shows community follow-up comments from the mailing list
  alongside your own.
- AI agent integration — optionally invoke an external AI agent
  (Claude Code, Gemini CLI, OpenAI Codex CLI, or GitHub Copilot CLI)
  to produce a first-pass review. Agent findings remain private to
  you; you decide what, if anything, to include in your reply.
- Per-patch state machine — mark individual patches as done, skip, or
  draft to track your progress through large series. B4 automatically
  excludes skipped patches from cherry-pick selection and outgoing
  emails.
- Three take strategies — merge (creates a merge commit from the
  cover letter), linear (git am), or cherry-pick (select individual
  patches). B4 adds per-commit Signed-off-by and Link trailers on
  request.
- Snooze — defer a series until a specific date, duration, or git
  tag. B4 skips snoozed series during bulk updates and automatically
  wakes them when the snooze expires.
- Cross-machine synchronisation — push b4/review/* branches to a
  private remote and rescan on another machine to rebuild the tracking
  database from branch metadata.
- Mutt-style thread viewer — press "e" to browse the full email thread
  with tree art, attestation status display, and reply support. B4
  tracks per-message flags (seen, flagged, answered) across sessions.
- Worktree support — enrolled repositories work correctly from
  worktrees; a configurable review-target-branch sets the default
  branch for take operations.
- Patchwork state synchronisation — when you have write access to a
  Patchwork instance, b4 automatically updates the remote series state
  as you progress through the review lifecycle.
- Prior review context — when upgrading to a new revision, b4 carries
  forward your previous review comments and notes so you can see what
  you said last time.
- Quick-reply — reply to follow-up messages directly from the review
  TUI or thread viewer without switching to your email client.

# b4 dig — trace applied commits back to mailing list submissions

The new "b4 dig" command searches for the original mailing list
submission of a commit that has already been applied to a git tree. It
matches by patch-id, author, and subject to locate the original thread
on lore.kernel.org.

    b4 dig <commitish>
    b4 dig --all-series HEAD~20..HEAD
    b4 dig --who --save-mbox <commitish>

# b4 shazam — three-way merge and conflict resolution

"b4 shazam -H" now performs a three-way merge when applying patches,
which significantly improves the success rate for series that do not
apply cleanly with a simple "git am". When conflicts do occur, the new
--resolve flag drops you into an interactive conflict resolution session
instead of aborting:

    b4 shazam -H --resolve <msgid>

# b4 prep — pre/post history-rewrite hooks

Two new configuration keys let you run commands before and after b4
rewrites history on a prep branch (for example, when updating the cover
letter or applying trailers via git-filter-repo):

    [b4]
        prep-pre-rewrite-hook = stg commit --all
        prep-post-rewrite-hook = stg repair

A non-zero exit from the pre-hook aborts the operation, which is useful
for tools like StGit that need to commit their internal state first.

Other notable changes
---------------------

- XOAUTH2 and bearer-token SMTP authentication
- Presubject support (b4.send-presubject / --set-presubject)
- Send-email alias expansion (sendemail.aliasesfile)
- Codespell integration in b4 prep --check
- Shallow same-thread support (b4.send-same-thread = shallow)
- Force cover letter for single-patch series (--force-cover-letter)
- Default Link domain changed to patch.msgid.link
- Full-index binary diffs (--full-index --binary)
- Clean multiple prep branches at once
- Thank-you self-copy (b4 ty --me-too)
- Range-diff arguments (--range-diff-opts)
- Trailer provenance display in b4 trailers

Thanks
------

Thanks to the following people for reporting bugs, suggesting features,
reviewing patches, testing, and contributing code, and especially to Mark
Brown for valiantly trying the very early, rough versions of b4 review
workflows.

Alexey Minnekhanov, Andrew Cooper, Andy Shevchenko, Christian Heusel,
Conor Dooley, Dave Marquardt, Geert Uytterhoeven, Jonathan Corbet,
Junio C Hamano, Juri Lelli, Kevin Hilman, Krzysztof Kozlowski,
Lee Jones, Linus Torvalds, Louis Chauvet, Luca Ceresoli,
Manos Pitsidianakis, Marc Kleine-Budde, Mark Brown, Matthieu Baerts,
Maxime Ripard, Michael S. Tsirkin, Miguel Ojeda, Nathan Chancellor,
Panagiotis Vasilopoulos, Ricardo Ribalda, Rob Herring,
Tamir Duberstein, Toke Høiland-Jørgensen.

Best regards,
-- 
KR

RE: b4 v0.15.0 released

[Luck, Tony]

> # b4 dig — trace applied commits back to mailing list submissions
>
> The new "b4 dig" command searches for the original mailing list
> submission of a commit that has already been applied to a git tree. It
> matches by patch-id, author, and subject to locate the original thread
> on lore.kernel.org.
>
>     b4 dig <commitish>
>     b4 dig --all-series HEAD~20..HEAD
>     b4 dig --who --save-mbox <commitish>

Not working for me. Tried on a random commit (that has a Link: tag, so should
be an easy case):

$ b4 --version
0.15.0
$ b4 dig 9395b1bb1f14
usage: b4 [-h] [--version] [-d] [-q] [-n] [--offline-mode] [--no-stdin] [-c NAME=VALUE]
          {mbox,am,shazam,review,pr,ty,diff,kr,prep,trailers,send,dig} ...
b4: error: unrecognized arguments: 9395b1bb1f14

-Tony

Re: b4 v0.15.0 released

[Konstantin Ryabitsev]

On Fri, Mar 20, 2026 at 09:11:00PM +0000, Luck, Tony wrote:
> >     b4 dig <commitish>
> >     b4 dig --all-series HEAD~20..HEAD
> >     b4 dig --who --save-mbox <commitish>
> 
> Not working for me. Tried on a random commit (that has a Link: tag, so should
> be an easy case):
> 
> $ b4 --version
> 0.15.0
> $ b4 dig 9395b1bb1f14
> usage: b4 [-h] [--version] [-d] [-q] [-n] [--offline-mode] [--no-stdin] [-c NAME=VALUE]
>           {mbox,am,shazam,review,pr,ty,diff,kr,prep,trailers,send,dig} ...
> b4: error: unrecognized arguments: 9395b1bb1f14

Sorry, the release notes swallowed the "-c":

    b4 dig -c 9395b1bb1f14

Regards,
-- 
KR

Re: b4 v0.15.0 released

[Jiri Slaby]

On 20. 03. 26, 21:47, Konstantin Ryabitsev wrote:
> Hi, all:
> 
> B4 v0.15.0 is now available! Install or upgrade using your usual mechanism.

Hi,

the TUI tests fail for me (while packaging for openSUSE):

> FAILED src/tests/test_tui_tracking.py::TestTrackingAppStartup::test_empty_database - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingAppStartup::test_series_listed - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingAppStartup::test_title_shows_identifier_and_count - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingAppStartup::test_series_sorted_by_added_at - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingNavigation::test_jk_navigation - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingNavigation::test_help_opens_and_closes - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingLimit::test_limit_filters_by_subject - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingLimit::test_limit_filters_by_sender - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingLimit::test_clear_limit - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingLimit::test_limit_title_shows_count - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingLimitPrefixes::test_limit_by_status - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingStatusGroups::test_actionable_before_non_actionable - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingStatusGroups::test_archived_not_shown - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingFocusChangeId::test_focus_on_specific_series - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingQuit::test_q_exits - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingActionMenu::test_action_menu_for_new_series - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingActionMenu::test_action_menu_for_snoozed - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingActionMenu::test_enter_on_new_opens_action_menu - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingUpgradeNewSeries::test_action_menu_shows_upgrade_for_new_with_newer - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingUpgradeNewSeries::test_action_menu_no_upgrade_without_newer - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingUpgradeNewSeries::test_upgrade_switches_revision - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingSnooze::test_snooze_new_series - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingSnooze::test_snooze_cancel - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingAbandon::test_abandon_new_series - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingAbandon::test_abandon_cancel - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingDetailPanel::test_detail_panel_shows_on_highlight - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingDetailPanel::test_detail_panel_hides_on_escape - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingDetailPanel::test_detail_panel_updates_on_navigation - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTrackingSnoozeRemembersChoice::test_snooze_remembers_last_input - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestSeriesLifecycle::test_new_directly_to_snoozed - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestSeriesLifecycle::test_gone_series_actions - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestTargetBranch::test_target_branch_in_details - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestUpdateRevisionWorkflow::test_prepared_none_is_noop - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestUpdateRevisionWorkflow::test_prepared_pushes_base_selection - RuntimeError: Not inside a git repository
> FAILED src/tests/test_tui_tracking.py::TestUpdateRevisionWorkflow::test_base_selected_none_cancels - RuntimeError: Not inside a git repository

I use the released .tar, so there is indeed no .git. Doing:

--- a/src/b4/ty.py        2026-03-24 07:24:14.713405924 +0100
+++ b/src/b4/ty.py       2026-03-24 08:19:47.936368274 +0100
@@ -682,7 +681,7 @@
      """
      gitdir = b4.git_get_common_dir()
      if not gitdir:
-        raise RuntimeError('Not inside a git repository')
+        gitdir = '.'
      qdir = os.path.join(gitdir, 'b4-review', 'queue')
      if dryrun:
          qdir = os.path.join(qdir, 'dryrun')


makes this work -- whether this is correct, I don't know.

Then, there is one more failure:

> ____________________________________________________ TestTrackingAbandon.test_abandon_new_series _____________________________________________________
> 
> self = <tests.test_tui_tracking.TestTrackingAbandon object at 0x7f2f1db36850>
> tmp_path = PosixPath('/tmp/pytest-of-abuild/pytest-18/test_abandon_new_series0')
> 
>     @pytest.mark.asyncio
>     async def test_abandon_new_series(self, tmp_path: pathlib.Path) -> None:
>         """Abandoning a new series should remove it from the DB."""
>         identifier = 'test-abandon'
>         _seed_db(identifier, [
>             {
>                 'change_id': 'keep-1',
>                 'subject': '[PATCH] keep me',
>                 'sent_at': '2026-03-10T11:00:00+00:00',
>                 'message_id': 'keep@ex.com',
>             },
>             {
>                 'change_id': 'abandon-1',
>                 'subject': '[PATCH] abandon me',
>                 'sent_at': '2026-03-10T12:00:00+00:00',
>                 'message_id': 'abandon@ex.com',
>             },
>         ])
>     
>         app = TrackingApp(identifier)
>         async with app.run_test(size=(120, 30)) as pilot:
>             await pilot.pause()
>             # First series is 'abandon-1' (last inserted, added_at desc)
>             assert app._selected_series is not None
>             assert app._selected_series['change_id'] == 'abandon-1'
>     
>             await pilot.press('a')
>             await pilot.pause()
>             assert isinstance(app.screen, ActionScreen)
>     
>             # Select 'abandon' from the menu
>             await pilot.press('A')  # shortcut for abandon
>             await pilot.pause()
>     
>             # Should show confirm dialog
>             assert isinstance(app.screen, ConfirmScreen)
>     
>             await pilot.press('y')
>             await pilot.pause()
>     
>             # Verify the abandoned series is gone from DB
>             conn = tracking.get_db(identifier)
>             cursor = conn.execute('SELECT change_id FROM series')
>             remaining = [row[0] for row in cursor.fetchall()]
>             conn.close()
>             assert 'keep-1' in remaining
>>           assert 'abandon-1' not in remaining
> E           AssertionError: assert 'abandon-1' not in ['abandon-1', 'keep-1']
> 
> src/tests/test_tui_tracking.py:1076: AssertionError
> ----------------------------------------------------------------- Captured log setup -----------------------------------------------------------------
> DEBUG    b4:__init__.py:3047 Running git --no-pager rev-parse --show-toplevel
> DEBUG    asyncio:selector_events.py:64 Using selector: EpollSelector
> ----------------------------------------------------------------- Captured log call ------------------------------------------------------------------
> DEBUG    b4:__init__.py:3047 Running git --no-pager rev-parse --git-common-dir
> DEBUG    b4:__init__.py:3047 Running git --no-pager rev-parse --show-toplevel
> DEBUG    b4:__init__.py:3047 Running git --no-pager rev-parse --show-toplevel
> DEBUG    b4:__init__.py:3047 Running git --no-pager rev-parse b4/review/abandon-1
> DEBUG    b4:__init__.py:3047 Running git --no-pager rev-parse b4/review/keep-1
> DEBUG    b4:__init__.py:3047 Running git --no-pager rev-parse --git-common-dir
> DEBUG    b4:__init__.py:3047 Running git --no-pager rev-parse --show-toplevel
> DEBUG    b4:__init__.py:3047 Running git --no-pager rev-parse --show-toplevel
> DEBUG    b4:__init__.py:3047 Running git --no-pager rev-parse --show-toplevel
> DEBUG    b4:__init__.py:3047 Running git --no-pager rev-parse b4/review/abandon-1
> DEBUG    b4:__init__.py:3047 Running git --no-pager rev-parse --show-toplevel
> ============================================================== short test summary info ===============================================================
> FAILED src/tests/test_tui_tracking.py::TestTrackingAbandon::test_abandon_new_series - AssertionError: assert 'abandon-1' not in ['abandon-1', 'keep-1']

thanks,
-- 
js
suse labs

Re: b4 v0.15.0 released

[Konstantin Ryabitsev]

On Tue, Mar 24, 2026 at 08:26:15AM +0100, Jiri Slaby wrote:
> On 20. 03. 26, 21:47, Konstantin Ryabitsev wrote:
> > Hi, all:
> > 
> > B4 v0.15.0 is now available! Install or upgrade using your usual mechanism.
> 
> Hi,
> 
> the TUI tests fail for me (while packaging for openSUSE):

Ack, that's true, I never tried running them outside the git repo. I'll check
it out and cut 0.15.1 when fixed.

bugspray tag b4/tests

-- 
KR

Re: b4 v0.15.0 released

[Konstantin Ryabitsev]

On Tue, Mar 24, 2026 at 08:49:51AM -0400, Konstantin Ryabitsev wrote:
> Ack, that's true, I never tried running them outside the git repo. I'll check
> it out and cut 0.15.1 when fixed.
> 
> bugspray tag b4/tests

These should be fixed an there's a 0.15.1 tarball available.

-- 
KR

Re: b4 v0.15.0 released

[Jiri Slaby]

On 24. 03. 26, 15:19, Konstantin Ryabitsev wrote:
> On Tue, Mar 24, 2026 at 08:49:51AM -0400, Konstantin Ryabitsev wrote:
>> Ack, that's true, I never tried running them outside the git repo. I'll check
>> it out and cut 0.15.1 when fixed.
>>
>> bugspray tag b4/tests
> 
> These should be fixed an there's a 0.15.1 tarball available.

Confirmed, thanks.

-- 
js
suse labs

Re: b4 v0.15.0 released

[B4 Bugbot]

Hello:

This conversation is now tracked by b4 bug tracker.
There is no need to do anything else, just keep talking.

--
Deet-doot-dot, I am a bot.
b4 bug tracker (bugspray 0.1-dev)

Re: b4 v0.15.0 released

[Konstantin Ryabitsev]

On Tue, Mar 24, 2026 at 01:03:47PM -0300, Arnaldo Carvalho de Melo wrote:
> Can this be integrated with sashiko? I.e. starting an AI review and waiting
> for it to complete takes time, if 'b4 review' could query sashiko if it had
> reviewed already can save time.

It is, but since sashiko.dev is very new, there are rough edges around the
integration (such as not properly handling reviews that are still pending).

https://b4.docs.kernel.org/en/latest/config.html#term-b4.sashiko-url

-K

Re: b4 v0.15.0 released

[Borislav Petkov]

On March 24, 2026 6:13:15 PM UTC, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
>On Tue, Mar 24, 2026 at 01:03:47PM -0300, Arnaldo Carvalho de Melo wrote:
>> Can this be integrated with sashiko? I.e. starting an AI review and waiting
>> for it to complete takes time, if 'b4 review' could query sashiko if it had
>> reviewed already can save time.
>
>It is, but since sashiko.dev is very new, there are rough edges around the
>integration (such as not properly handling reviews that are still pending).
>
>https://b4.docs.kernel.org/en/latest/config.html#term-b4.sashiko-url
>
>-K
>

I hope you guys are planning on sending the sashiko reviews as replies to the patches... eventually, ofc. Would be useful.

Thx
-- 
Small device. Typos and formatting crap

Re: b4 v0.15.0 released

[Theodore Tso]

On Wed, Mar 25, 2026 at 10:19:19AM +0000, Borislav Petkov wrote:
> I hope you guys are planning on sending the sashiko reviews as
> replies to the patches... eventually, ofc. Would be useful.

There's a thread about this, but channelling the Sashiko team (it's a
separatae effort from Konstantin's b4 project, nb4 is just using
Sashiko), they want to get the false positive vs useful detections
rate to the point where the reviews won't be considered annoying, and
then it will probably be on a per-subsystem opt-in basis.  There's
been talk of having an option about whether the reviews should go to
the maintainers and the patch submitter, or whether the subsystem list
should be cc'ed as well.  But all of this is still TBD.

Cheers,

						- Ted

Re: b4 v0.15.0 released

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

On Wed, Mar 25, 2026 at 07:50:29AM -0500, Theodore Tso wrote:
> On Wed, Mar 25, 2026 at 10:19:19AM +0000, Borislav Petkov wrote:

> > I hope you guys are planning on sending the sashiko reviews as
> > replies to the patches... eventually, ofc. Would be useful.

> There's a thread about this, but channelling the Sashiko team (it's a
> separatae effort from Konstantin's b4 project, nb4 is just using
> Sashiko), they want to get the false positive vs useful detections
> rate to the point where the reviews won't be considered annoying, and
> then it will probably be on a per-subsystem opt-in basis.  There's
> been talk of having an option about whether the reviews should go to
> the maintainers and the patch submitter, or whether the subsystem list
> should be cc'ed as well.  But all of this is still TBD.

Right now even where it's accurate the reports it's generating are
pretty annoying TBH due to it flagging preexisting issues it happens to
notice through the same channel as it's reporting problems with the
patch itself.  If they were reported separately it'd be useful but right
now they just make these reviews not a useful indication if there's a
problem with the patches.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]