[RFC] b4 review: an "inbox" view for series addressed to me

[RFC] b4 review: an "inbox" view for series addressed to me

[Vasileios Almpanis]

Hi all,

I would like to propose (and implement) a discovery feature for b4 review
and would appreciate feedback on scope and design before I write any code.

Problem
---

b4 review tui only shows series that were explicitly added using b4 review
track. Finding what I'm expected to look at is still done manually. Open my
client, check my messages, find the message-id, run b4 review track 
message-id.
For someone CC'd as a reviewer/maintainer on a handful of areas, an inbox of
series that were addressed to me and that I haven't dealt with yet would 
remove
the above tedious work.

Proposal
---

A new b4 review command (b4 review inbox) and a keybinding in b4 review 
tui that:

1. Queries public inbox for recent series roots addressed to me:
    tc:<my-addr> AND NOT s:Re: AND dt:<lookback>.. filtered client-side 
to cover
    letters / patch 1. The set of "my" addresses would be configurable
    (b4.review-inbox-days, b4.review-inbox-addrs, falling back to 
user.email).

2. Annotates each series with best-effort state:
    - "replied": a Reviewed-by/Acked-by/Tested-by or any reply from me
      exists in the thread;
    - "in tree": patch-ids found in a configured upstream ref.
    - patchwork state, when the project has a PW instance configured.

3. Offers actions: track, open thread, refresh.

Open questions
---

- Is tc: the right signal for "I'm a reviewer", or should it also
   consult MAINTAINERS / get_maintainer.pl?
- Is there prior work on something like this or similar that I should
   align with?

Happy to adjust or drop any of this based on feedback.

-- 
Best regards, Vasileios Almpanis
Software Developer, Virtuozzo.

Re: [RFC] b4 review: an "inbox" view for series addressed to me

[Konstantin Ryabitsev]

On Fri, Aug 28, 2026 at 02:42:35PM +0200, Vasileios Almpanis wrote:
> Hi all,
> 
> I would like to propose (and implement) a discovery feature for b4 review
> and would appreciate feedback on scope and design before I write any code.

Hi! Happy to discuss this -- but this is already a planned feature. Check
plan.otl, there is a large section titled "auto-consume a public-inbox
archive".

> Problem
> ---
> 
> b4 review tui only shows series that were explicitly added using b4 review
> track. Finding what I'm expected to look at is still done manually. Open my
> client, check my messages, find the message-id, run b4 review track
> message-id.
> For someone CC'd as a reviewer/maintainer on a handful of areas, an inbox of
> series that were addressed to me and that I haven't dealt with yet would
> remove
> the above tedious work.

Correct, though notably it's less tedious when patchwork is present. However,
this needs to work without patchwork as well.

> 
> Proposal
> ---
> 
> A new b4 review command (b4 review inbox) and a keybinding in b4 review tui
> that:

I had a different solution in mind -- instead of extending b4 review, we have
an entirely different tui that I was calling "b4 maintain" in my head. There
are three main categories of things that a maintainer needs to keep an eye on
-- incoming series, bug reports, and general correspondence. The maintainer
tui would give an at-a-glance overview and additionally allow for agent
integration as a background task:

- analyze bug reports, check for duplicates, assign priority
- automatically feed new and updated series into "b4 review"
- summarize discussions and bubble up threads that clearly need a decision

Basically, avoid the firehose and help maintainers not dread opening up their
inbox in the morning.

> 1. Queries public inbox for recent series roots addressed to me:
>    tc:<my-addr> AND NOT s:Re: AND dt:<lookback>.. filtered client-side to
> cover
>    letters / patch 1. The set of "my" addresses would be configurable
>    (b4.review-inbox-days, b4.review-inbox-addrs, falling back to
> user.email).

This is already implemented in korgalore, so the plan is to reuse that either
directly or by shipping a lot of this functionality into the existing "ezpi"
library.

> 2. Annotates each series with best-effort state:
>    - "replied": a Reviewed-by/Acked-by/Tested-by or any reply from me
>      exists in the thread;
>    - "in tree": patch-ids found in a configured upstream ref.
>    - patchwork state, when the project has a PW instance configured.

Okay, these are all easy heuristics.

> 3. Offers actions: track, open thread, refresh.
> 
> Open questions
> ---
> 
> - Is tc: the right signal for "I'm a reviewer", or should it also
>   consult MAINTAINERS / get_maintainer.pl?

korgalore attempts to approach this with "kgl track-subsystem".

> - Is there prior work on something like this or similar that I should
>   align with?

Yes, both prior work and a planned feature. :)

Thanks,
-K

Re: [RFC] b4 review: an "inbox" view for series addressed to me

[Vasileios Almpanis]

On 8/28/26 4:19 PM, Konstantin Ryabitsev wrote:
> On Fri, Aug 28, 2026 at 02:42:35PM +0200, Vasileios Almpanis wrote:
>> Hi all,
>>
>> I would like to propose (and implement) a discovery feature for b4 review
>> and would appreciate feedback on scope and design before I write any code.
> Hi! Happy to discuss this -- but this is already a planned feature. Check
> plan.otl, there is a large section titled "auto-consume a public-inbox
> archive".
>
>> Problem
>> ---
>>
>> b4 review tui only shows series that were explicitly added using b4 review
>> track. Finding what I'm expected to look at is still done manually. Open my
>> client, check my messages, find the message-id, run b4 review track
>> message-id.
>> For someone CC'd as a reviewer/maintainer on a handful of areas, an inbox of
>> series that were addressed to me and that I haven't dealt with yet would
>> remove
>> the above tedious work.
> Correct, though notably it's less tedious when patchwork is present. However,
> this needs to work without patchwork as well.
>
>> Proposal
>> ---
>>
>> A new b4 review command (b4 review inbox) and a keybinding in b4 review tui
>> that:
> I had a different solution in mind -- instead of extending b4 review, we have
> an entirely different tui that I was calling "b4 maintain" in my head. There
> are three main categories of things that a maintainer needs to keep an eye on
> -- incoming series, bug reports, and general correspondence. The maintainer
> tui would give an at-a-glance overview and additionally allow for agent
> integration as a background task:
>
> - analyze bug reports, check for duplicates, assign priority
> - automatically feed new and updated series into "b4 review"
> - summarize discussions and bubble up threads that clearly need a decision
>
> Basically, avoid the firehose and help maintainers not dread opening up their
> inbox in the morning.
The case I was actually interested in is a normal reviewer: someone
who gets cc'd by get_maintainer/Fixes across unrelated subsystems and
doesn't maintain any of them.

As far as I can tell from the korgalore docs, that person could
subscribe a lei saved search (tc:<me> AND NOT f:<me>) as a feed into a
pipe target running "b4 review consume". But the setup is: install
public-inbox for lei, configure a remote external, set up korgalore
and a timer, etc.
For a maintainer this makes sense. For someone who reviews a few patches
a month it is a lot compared to a single lore query at the time they want to
look.

Do you think that setup is reasonable to expect from the average
reviewer, or is there room for an on-demand query mode alongside the
korgalore path?
>
>> 1. Queries public inbox for recent series roots addressed to me:
>>     tc:<my-addr> AND NOT s:Re: AND dt:<lookback>.. filtered client-side to
>> cover
>>     letters / patch 1. The set of "my" addresses would be configurable
>>     (b4.review-inbox-days, b4.review-inbox-addrs, falling back to
>> user.email).
> This is already implemented in korgalore, so the plan is to reuse that either
> directly or by shipping a lot of this functionality into the existing "ezpi"
> library.
>
>> 2. Annotates each series with best-effort state:
>>     - "replied": a Reviewed-by/Acked-by/Tested-by or any reply from me
>>       exists in the thread;
>>     - "in tree": patch-ids found in a configured upstream ref.
>>     - patchwork state, when the project has a PW instance configured.
> Okay, these are all easy heuristics.
>
>> 3. Offers actions: track, open thread, refresh.
>>
>> Open questions
>> ---
>>
>> - Is tc: the right signal for "I'm a reviewer", or should it also
>>    consult MAINTAINERS / get_maintainer.pl?
> korgalore attempts to approach this with "kgl track-subsystem".
>
>> - Is there prior work on something like this or similar that I should
>>    align with?
> Yes, both prior work and a planned feature. :)
>
> Thanks,
> -K

-- 
Best regards, Vasileios Almpanis
Software Developer, Virtuozzo.