b4 review tui + lore/lei/korgalore
Christian Brauner <[email protected]> Tue, 30 Jun 2026 16:12:47 +0200
| Newsgroups | org.kernel.linux.tools |
|---|---|
| Message-ID | <20260630-einhundert-bauamt-atemlos-5b92514a1443@brauner> |
Hey Konstantin,
So I've now been working with b4 review tui exclusively for a while and
have added a bunch of extensions that put it on steroids for me. In
place merge conflict resolution when applying individual patches or
series is just "chef's kiss".
I also do like the patchwork integration which is very nice and allows
me to pick series from patchwork into b4 review tui without much effort.
One thing that I'm missing is a companion to the patchwork app
integration for mailing lists. Here's what I mean. I want to be able to
browse a mailing list the same way I'm browsing the patchwork app ('p')
in b4 review tui, then mark them as "tracked" etc (ideally it would
de-duplicate by message-id or something between the patchwork app and
the mailing list.
I'm not well-versed enough in lore/lei/korgalore to find the correct
integration point for this so this makes sense.
Here's some proposals that I came up with talking to an LLM:
The shared idea (both D and C)
Both add the same feature — a browse-and-pick LoreListApp (a lore-native
sibling of the Patchwork browser PwApp): it lists new patch series
discovered from lore mailing lists, you eyeball them, press t to enroll
one into the existing review tracker. They share the entire spine and
differ only in the transport that produces messages:
- The seam is a List[EmailMessage] → _get_lore_series → add_series_to_db
(b4 already owns all of this).
- A lore_scan.py series-scanner: LoreSubject finds [PATCH vN m/n] roots
→ get_strict_thread groups → find_existing_change_id dedups → emits
candidate-series rows.
- Entry wiring: a LORE_SENTINEL + g binding in TrackingApp, and
run_lore_tui in _entry.py, exactly mirroring how p opens Patchwork.
- Tracking reuses add_series_to_db with pw_series_id=None (identity via
change-id/fingerprint).
Option D — native public-inbox git
b4 mirrors and walks the lore git repos itself. Transport is
lore_mirror.py, a port of korgalore's pi_feed/lore_feed: fetch
manifest.js.gz → auto-discover v2 epochs → git clone --mirror →
incremental git rev-list {cursor}..HEAD → read each commit's m blob →
parse → scan into series. Per-epoch OID cursor + rebase-recovery for
when lore repacks.
- Pros: fully self-contained and offline, zero external tools, replaces
l2md outright; the public-inbox reader is upstreamable into the shared
liblore later.
- Cons: b4 carries ~1000 lines of git plumbing;
subsystem-by-touched-file discovery (fs/**) isn't free — by-List-Id is
easy, by-file would need local indexing.
- Note: plan.otl already has a v0.17 "Auto-consume / b4 review consume"
item that instead delegates the walking to korgalore's pipe target — D
is the b4-native-walk alternative and should reconcile with it.
Option C — lei-backed
b4 shells out to lei (public-inbox's local email interface). Transport
is lore_lei.py: build a query (l:<list-id> and/or dfn:<glob>
touched-file), run lei q -I https://lore.kernel.org/all/ -t -o
<maildir>, refresh incrementally with lei up, parse the Maildir → scan
into series.
- Pros: least new b4 code; gives server-side dfn: touched-file search —
"show me every new series touching fs/**" — which is the maintainer
superpower Patchwork can't match; korgalore already proves the
pattern. No local mirror needed (queries lore over HTTP).
- Cons: runtime dependency on lei being installed/configured; hybrid-online.
┌───────────────────┬─────────────────────────────────────┬─────────────────────────────────┐
│ │ D — native git │ C — lei │
├───────────────────┼─────────────────────────────────────┼─────────────────────────────────┤
│ Transport │ b4 walks v2 epochs (lore_mirror.py) │ shell out to lei (lore_lei.py) │
├───────────────────┼─────────────────────────────────────┼─────────────────────────────────┤
│ External dep │ none │ lei │
├───────────────────┼─────────────────────────────────────┼─────────────────────────────────┤
│ Offline │ ✅ full │ hybrid (HTTP queries) │
├───────────────────┼─────────────────────────────────────┼─────────────────────────────────┤
│ Subsystem-by-file │ needs indexing │ ✅ free (dfn:) │
├───────────────────┼─────────────────────────────────────┼─────────────────────────────────┤
│ New b4 code │ most (~1000 lines git) │ least │
└───────────────────┴─────────────────────────────────────┴─────────────────────────────────┘
I don't think I can work on this but I would really love to see a variant of this happening.
I'm not tied to any specific form I just want to get the idea of a
mailing list/mbox/lore/korgalore/lei type browser app like the patchwork app in b4 review tui.
I think that would be an absolute killer feature.
Thanks!
Christian