Patchboards

Patcboards is my concept for a friendly UI for mailing list based patch workflows, like that used by the Linux kernel.

Original notes#

Back in 2024, I posted:

with some wrangling, you *could* make a gitlab mr-like ui for mailing list patch systems:

- a patch series is represented by a specific git branch (b4 already does this) and a specific "merge request" in the frontend

- if we're smart about it, the code itself might not even need to be hosted in the same place as the frontend (ie. the frontend is not the git server). it does make it easier but it also takes up a lot more storage, especially for big projects like the linux kernel

- pushing changes to the branch will push them to the ui so you can check them, but it will *not* send them - that's done with a separate button (with a timeout so you don't send a minor fix 5 minutes after send - we don't do that on the mailing lists, and i keep forgetting).

- sending will automatically increase the version, but the branch/mr stays the same (just gets a badge saying "this is version 2").

- a nice way to implement this would be to create a tag for each version. that way, you can diff between the latest branch and the last submitted version (kind of like you can do on gitlab with different revisions).

- review comments are collected from email replies and gitlab-like comment threads are created. see prior work in this e.g. patchwork or sourcehut lists.

- replying is a bit faster - you write the replies, save them, then hit another send button to merge it all into one e-mail (preferably with an UI to customize the reply before you send it). closest analogy to this i can think of is like starting a review in a gitlab mr, but for replying to someone? idk.

there are a few things that this kind of solution addresses compared to using the existing bundle of tools.

- i often find that i accidentally introduce regressions while rebasing a patch series for submission. it's usually small issues that are tough to catch initially. it would be nice to be able to diff it in a nice ui, kind of like i can with different revisions of a gitlab mr, before i submit the patch.

- replying to emails is not that bad, but i do find myself missing the convenience of replies/review blocks sometimes, especially in very large reviews with lots of quotes. at some point the likelihood of accidentally missing a point of a review because of the amount of quotes starts becoming higher, so having a more streamlined ui like on gitlab MRs would help

I also drew this professional diagram of the workflow and involved data types:

here's the workflow:

- a "Board" is kind of like a mailing list in that it's a collection of patchsets, you can either create a patchset from the ui or import it from an email
- a patchset shows up in a UI that's kind of like a GitLab MR.
- to add commits to a patchset, you can:
- push changes to a git repo that is linked to this branch OR
- send an email to the patchboards server with the patches OR
- just submit the patchset directly if you don't use any of the goodies like CI, and let the server detect your email in your inbox
- otherwise, you can send the patchset and its subsequent versions off through the web ui (a cli is planned too).

as mentioned earlier, this lets you have nice features such as pre-send CI (useful for people who tend to rush things like meeee :D), a more modern way to reply to reviews and analyze them, and a way to preview your changes in a ui with fancy syntax highlighting before you send your patch

The project began development with a stack based on Python and Flask. (I have yet to port it to Quart.) I ended up getting stuck on the question of how to implement the whole email storage concept on the back end - I wasn't too sure about storing these things in SQL. (I generally don't vibe with SQL… it doesn't fit my way of thinking about objects and relations. At some point I wanted to do a rewrite in Quart and some ORM solution, but I already forgot which library it was…)