Re: b4 review available in master

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Wed, Mar 18, 2026 at 10:47:07AM -0600, Jonathan Corbet wrote:
> 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.

What to trim and what not to trim is a question that will likely never
receive a single answer. I find it (slightly) annoying when people start
a conversation about a patch design in the text of the cover letter and
leave 1000 lines of diffstat below, but I find it more frustrating when
someone trims a patch agressively in their review and I end up not being
able to comment in my reply to both their comments and related parts of
the patch that they trimmed out.

The obvious answer is "trim exactly the way I would". I have had very
little success preaching that so far.

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

That's a style I sometimes use, usually not in the first e-mail reply,
but quite often when the mail thread is 10 replies deep and it becomes
clear large areas of the original patch are just not relevant to the
discussion any more.

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

-- 
Regards,

Laurent Pinchart