Re: b4 review available in master

Konstantin Ryabitsev
2026-03-18T19:22:13Z

On Wed, Mar 18, 2026 at 10:47:07AM -0600, Jonathan Corbet wrote:
> > However, I am now curious to hear your feedback. The idea with the review app
> > is that you are not really sending an email, you're adding comments to code
> > and adding review trailers. The app will render and send that out for you,
> > trimming and formatting things nicely so you don't have to do it on your own
> > (I've noticed that many maintainers don't bother anyway -- there are emails
> > with a terse comment at the top and then a huge quoted bottom that is only
> > followed by their sig.
>
> This is just me, of course ... and I was very much experimenting with it
> as an alternative to my usual "do it in email" approach. So one can
> definitely argue that I was simply holding it wrong.

I think it will help to look at not as an alternative to "do it in email" but
"do it alongside email." Email works great for person-to-person communication,
in-depth philosophical discussions, etc. But these are all fun and exciting
things about participating in Linux development already. What b4 review aims
to address is the "dull and boring" parts of participating in Linux
development:

- look through all diffs
- look at CI results
- drop to shell, poke around, run a local test

- send a quick Acked-by/Reviewed-by
- park it until you get a new revision

or

- take it in
- send a thanks
- archive it

> If, though, the intent is that one inserts comments and leaves the patch
> text alone, I think that the interface *really* needs to not let you
> mess with the stuff you're not supposed to change.

I went down that path. You could at some point insert comments via textual
pop-ups, but I hated it, because it's Not Like My Editor (also, see below).

> If one were to
> implement this as <obnoxious>an Emacs mode</obnoxious>, that sort of
> constraint could be implemented fairly easily. If you're throwing
> somebody into an arbitrary editor, it's going to be rather harder.

I've debated this with myself for so long! The reason the arbitrary editor won
is because it's so much easier to do powerful operations in it, including
things like: copy this original block of code, paste it and reformat it / edit
it to show how it should be done, add another buffer, edit the code there,
make sure it compiles, return to the original message, paste working code,
etc. All of this was dramatically more awkward when NOT done in your usual
favourite editor.

It only requires not looking at it as "sending an email" -- you're commenting
on code, don't treat this as the final email.

> I tend to be pretty careful about which text I trim when composing
> replies. It's pretty helpful to, for example, be able to do something
> like:
>
> > something from the patch
>
> Here you're doing X...
>
> [...]
> > something rather further down
>
> Here instead it's expecting Y, WTF?
>
> ...so I would be less than fully pleased with an interface that prevents
> that.

Noted! Again, this is supposed to work alongside your email client, so if you
find yourself constrained by the code review framework, you can always yank
that thread into your inbox (or reply from the lite email viewer that b4
review also provides).

> But perhaps I'm a dinosaur who just isn't using the tool correctly.

It *is* a bit of a challenge with the "users" crowd because everyone here is
very much already comfortable with their workflow. ;) Once 0.15 is out, I'm
hoping I get feedback from people who are not already well-established in
their ways (who, on the other hand, may find it awkward because it's "not like
Github").

> > Is this rife for creating confusion? Will maintainers be fighting with this
> > and growing grumpy because it's not exactly like their email client?
>
> Some surely will, see above. But that doesn't necessarily mean you're
> not creating a better workflow in the long run. I think we need to play
> with a lot of ideas, and I'm really glad you're doing that.

Great, thanks for the feedback!

--
KR