From: Konstantin Ryabitsev <mricon@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: users@kernel.org, tools@kernel.org
Subject: Re: b4 review available in master
Date: Wed, 18 Mar 2026 15:22:11 -0400 [thread overview]
Message-ID: <20260318-groovy-daring-echidna-e109fc@lemur> (raw)
In-Reply-To: <87se9x5blg.fsf@trenco.lwn.net>
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
next prev parent reply other threads:[~2026-03-18 19:22 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-27 19:53 b4 review available in master Konstantin Ryabitsev
2026-02-28 15:12 ` Mark Brown
2026-02-28 15:47 ` Konstantin Ryabitsev
2026-02-28 16:00 ` Konstantin Ryabitsev
2026-02-28 18:12 ` Mark Brown
2026-02-28 15:53 ` Mark Brown
2026-02-28 21:11 ` Mark Brown
2026-03-03 5:14 ` Konstantin Ryabitsev
2026-03-03 12:42 ` Mark Brown
2026-03-03 18:21 ` Konstantin Ryabitsev
2026-03-12 17:21 ` Alexandre Belloni
2026-03-13 15:42 ` Konstantin Ryabitsev
2026-03-13 15:55 ` Alexandre Belloni
2026-03-21 10:01 ` Alexandre Belloni
2026-03-12 17:35 ` Mark Brown
2026-03-13 15:42 ` Konstantin Ryabitsev
2026-02-28 16:36 ` Conor Dooley
2026-02-28 16:45 ` Konstantin Ryabitsev
2026-02-28 16:48 ` Conor Dooley
2026-02-28 16:57 ` Konstantin Ryabitsev
2026-02-28 17:00 ` Conor Dooley
2026-02-28 17:05 ` Konstantin Ryabitsev
2026-02-28 17:12 ` Conor Dooley
2026-02-28 17:21 ` Konstantin Ryabitsev
2026-02-28 17:34 ` Konstantin Ryabitsev
2026-02-28 18:37 ` Conor Dooley
2026-02-28 22:16 ` Conor Dooley
2026-02-28 22:32 ` Conor Dooley
2026-03-03 5:16 ` Konstantin Ryabitsev
2026-03-04 21:38 ` Conor Dooley
2026-03-04 22:40 ` Konstantin Ryabitsev
2026-03-04 22:55 ` Conor Dooley
2026-03-05 3:26 ` Konstantin Ryabitsev
2026-03-05 6:17 ` Konstantin Ryabitsev
2026-02-28 18:31 ` Michael S. Tsirkin
2026-02-28 20:06 ` Konstantin Ryabitsev
2026-02-28 20:23 ` Michael S. Tsirkin
2026-02-28 20:37 ` Konstantin Ryabitsev
2026-02-28 20:47 ` Michael S. Tsirkin
2026-02-28 20:53 ` Konstantin Ryabitsev
2026-02-28 21:04 ` Michael S. Tsirkin
2026-03-02 9:30 ` Michael S. Tsirkin
2026-03-02 10:33 ` Michael S. Tsirkin
2026-03-03 1:58 ` Junio C Hamano
2026-03-03 4:26 ` Konstantin Ryabitsev
2026-03-03 11:20 ` Matthieu Baerts
2026-03-04 20:56 ` range-diff hangs Marc Kleine-Budde
2026-03-14 4:20 ` Konstantin Ryabitsev
2026-03-14 9:27 ` Marc Kleine-Budde
2026-03-16 23:28 ` b4 review available in master Jonathan Corbet
2026-03-16 23:41 ` Jonathan Corbet
2026-03-17 0:15 ` Konstantin Ryabitsev
2026-03-17 14:11 ` Jonathan Corbet
2026-03-17 14:23 ` Konstantin Ryabitsev
2026-03-17 20:30 ` Konstantin Ryabitsev
2026-03-17 21:46 ` Jonathan Corbet
2026-03-17 22:39 ` Konstantin Ryabitsev
2026-03-17 23:37 ` Konstantin Ryabitsev
2026-03-18 7:56 ` Geert Uytterhoeven
2026-03-18 13:00 ` Mark Brown
2026-03-18 13:26 ` Konstantin Ryabitsev
2026-03-18 16:47 ` Jonathan Corbet
2026-03-18 18:31 ` Laurent Pinchart
2026-03-18 19:22 ` Konstantin Ryabitsev [this message]
2026-03-17 0:12 ` Konstantin Ryabitsev
2026-03-18 13:43 ` Johannes Thumshirn
2026-03-20 16:53 ` Louis Chauvet
2026-03-20 19:31 ` Konstantin Ryabitsev
2026-03-20 21:14 ` Alexandre Belloni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260318-groovy-daring-echidna-e109fc@lemur \
--to=mricon@kernel.org \
--cc=corbet@lwn.net \
--cc=tools@kernel.org \
--cc=users@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox