Re: b4 review available in master

[Konstantin Ryabitsev <mricon@kernel.org>]

On Tue, Mar 03, 2026 at 12:42:26PM +0000, Mark Brown wrote:
> > This was already kinda working, but it should work better now. "With privacy"
> > is the complicated part, because we really-really don't want to deal with
> > encryption and keys and all the stuff that comes with that. I recommend just
> > having a private remote where you can push your review branches. It's not very
> > well-documented, but you have a private space in
> > git@gitolite.kernel.org:scratch/broonie/ -- don't let the name "scratch" spook
> > you, it's just not replicated to git.kernel.org, that's all.
> 
> Yeah, pushing branches isn't a concern - it was more the database bit.

The database is mostly there as a caching layer. We do a "rescan" on each
application start and will update the database with whatever we find in actual
review branches. So, you should be able to push and pull between systems and
have it reasonably synchronized (bugs excepted). It's documented here:
https://b4.docs.kernel.org/en/latest/maintainer/review.html#setting-up-a-sync-remote

> > We can now define review-target-branch, but I don't think it's wired into the
> > "rebase" flow yet, just in the "take" flow. I'll make a note to check both.
> 
> I'd expect many people have at least fixes and -next branches in the
> same git repo (I have that, times four for each subsystem I have) so
> it'd need to be runtime selectable which branch to use.

Okay, I can't implement this as a combo box in textual, but it will now
remember the branches you use for merging and will offer the last branch you
used as the default entry, and if you start typing the name of another branch,
it will show up as an option to auto-complete (with right-arrow key).

> > This is "as designed" right now -- the Signed-off-by and Link trailers are
> > applied to the merge commit and leave the individual commits untouched. It's a
> > controversial take, I know. :)
> 
> > Would you prefer that we always applied Signed-off-by: and Link: to each
> > individual commit even if we're doing a merge?
> 
> *Especially* if we're doing a merge, I think the general expectation is
> that there will be a signoff from the person who committed the patch -
> in -next we check every commit for both author and committer signoffs.
> If we cherry pick and they get applied then that'd work out OK, but if
> we merge and the unsigned commits end up in -next that'd be an issue.
> Missing signoffs will also mess up with flows like cherry picking
> patches back into stable, the merge would be long gone by the time the
> commit shows up in stable.

OK, this is now working exactly as with "b4 shazam" and has the functionality
you're looking for.

> > I'll push back on this a little simply because there's a lot that is keyed off
> > the number of patches in the series. If we cherry-pick before we even review,
> > this makes a lot of other functionality fragile. However, there is code now to
> > mark patches as "skip" (with x) -- this should let you completely ignore them.
> > When we "take" a series with ignored patches we will automatically default to
> > the cherry-pick strategy and pre-unselect the ignored patches. Would that come
> > kinda close to what you want?
> 
> Possibly?  I'd need to try it.  Some of these serieses are quite large
> so even finding the relevant mails can be annoying.

Let me know if that's not sufficient. We can also give a way to hide skipped
patches so they aren't even in the picture.

> > I don't think I fixed this yet, but there's been churn in that code today. See
> > if it's still doing that.
> 
> Yeah, still seems to be present.

This should be now fixed.

There's also new functionality in the current master:

- "take" is now decoupled from "accept" -- you can take into any branch and
  the series won't be marked as "accepted" if you leave that checkbox
  unchecked
- you can snooze a series, including until we find a specific tag in the local
  tree; so, in theory, you could snooze a series until v7.0-rc3 or something
  like that

Thanks for the feedback, and I'll work on improving the comment/review/email
UI next once I collect a bit more feedback from others.

Cheers,
-- 
KR