Problems with b4 review update workflow

Problems with b4 review update workflow

[Mark Brown]

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

Hi Konstantin,

When you take a new version of a series it's possible that a rebase will
be required to get the new series to apply.  Unfortunately there is no
opportunity in the UI to select the base that a new version of a series
will be applied to, b4 just takes a stab at a base without seeking
confirmation (even if it detected that that base isn't a match) and then
if that doesn't work you're dropped into a shell in the middle of a git
am which makes it hard to repoint the base.

Worse, since b4 archives the old version of the series prior to trying
to take the new one you've compeletely lost track of the review - there
should be an unarchive on error.

Thanks,
Mark 

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

Re: Problems with b4 review update workflow

[Konstantin Ryabitsev]

On Thu, Mar 19, 2026, at 08:05, Mark Brown wrote:
> Hi Konstantin,
>
> When you take a new version of a series it's possible that a rebase will
> be required to get the new series to apply.  Unfortunately there is no
> opportunity in the UI to select the base that a new version of a series
> will be applied to, b4 just takes a stab at a base without seeking
> confirmation (even if it detected that that base isn't a match) and then
> if that doesn't work you're dropped into a shell in the middle of a git
> am which makes it hard to repoint the base.
>
> Worse, since b4 archives the old version of the series prior to trying
> to take the new one you've compeletely lost track of the review - there
> should be an unarchive on error.

Yes, that's not great. 

bugspray tag b4/review

Thanks!
-K

Re: Problems with b4 review update workflow

[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: Problems with b4 review update workflow

[B4 Bugbot]

Konstantin Ryabitsev writes in commit db13a1e6989d946ae12fc7acfd7ec38a61df2148:

review: use temporary upgrade branch for revision updates

Refactor _do_update_revision() into a three-phase workflow so the old
review branch is never modified until the new revision applies
successfully:

  Phase 1 (worker): fetch the new series from the network and compute
  base commit hints -- same logic used during initial checkout.

  Phase 2 (modal): show BaseSelectionScreen so the maintainer can see
  and correct the base commit, instead of silently guessing.

  Phase 3 (suspend): apply patches to a temporary upgrade branch
  (b4/review/{change_id}-v{rev}-upgrade), restore review data, then
  archive the old branch and rename the upgrade branch into place.

Previously the old review branch was archived (deleted) before
attempting to apply the new version, so a failed git-am left the
maintainer with no review data. Now the old branch stays untouched
until the apply succeeds. If anything goes wrong the upgrade branch
is cleaned up and the old review is intact.

After a successful upgrade the TUI returns to the tracking list
instead of immediately entering review mode.

Key changes:
- _do_update_revision() now pushes a WorkerScreen for the fetch phase
- New _on_update_prepared() callback pushes BaseSelectionScreen
- New _on_update_base_selected() does the apply/swap in suspend()
- Archive only happens after the upgrade branch is fully built
- git branch -m renames upgrade branch to review branch on success
- Added 8 tests covering all phases, failure modes, and the safety
  guarantee that the old branch survives errors

Reported-by: Mark Brown <broonie@kernel.org>
Closes: https://msgid.link/64a3ea45-bb7f-4a29-bce9-2dcf44ed7e25@sirena.org.uk # cc07a98
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Assisted-by: claude-opus-4-6

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