Re: b4 review available in master

[Jonathan Corbet <corbet@lwn.net>]

Konstantin Ryabitsev <mricon@kernel.org> writes:

> On Tue, Mar 17, 2026 at 06:39:54PM -0400, Konstantin Ryabitsev wrote:
>> > So it's still behaving a bit strangely, at least that's how it seems to
>> > me.  I tried adding comments to a patch, doing my usual trick of
>> > trimming out stuff that is being skipped over.
>> 
>> You don't need to do that. Just find the stuff you want commenting on. We'll
>> take care of the rest! :)
>> 
>> But, I'm able to reproduce what you're seeing -- trimming content doesn't do
>> the right thing. Let me see if I can make this a lot more relaxed.
>
> The current master should be a lot more forgiving when parsing your comments.
>
> 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.

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.  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 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.

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

> 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.

Thanks,

jon