On Thu, Feb 01, 2024 at 10:39:04AM -0500, Konstantin Ryabitsev wrote: > [excellent discussion of e-mail workflows elided] It would surely help if the e-mail interfaces of forges were not terrible. But they really have to be as good as the mailing list approach. I envision that the "issues" and "PRs" could be webmail-ish thread trackers that auto-close on prolonged silence. One could open issues/ PRs by e-mail, close them by e-mail, etc., all e-mails going to the same [forge-run?] list address, but still have a forge-style view of a PR's commits, still have a forge-style code review web UI (with all comments going to e-mail too, and with e-mail being first-class, not an afterthought), still have a CI checks UI, and still have a big rebase-and-merge button for maintainers. I.e., forge e-mail UI as first-class equivalent of forge web UI. The forges tend to be run by people who prioritize users who are not heavy e-mail workflow devs. It makes economic sense, given how few users demand e-mail as a first-class forge UI. Still, it would be quite awesome if some forge did this. > - How to avoid a vendor lock-in? [...] Assuming some forge exists with an e-mail UI on the same footing as its web UI, and also good enough for kernel/git/... devs, you could maintain mirrors on all the other forges, naturally, and always fallback on e-mail only if the primary forge disappears or becomes too expensive. > - How to avoid centralization and single points of failure? [...] It's all forks, all the time. It'd be good if the kernel maintainers maintained non-forge git servers as mirror/staging/primary repos. > - How to avoid alienating these hundreds of key maintainers who are now > extremely proficient at their query-based workflows? [...] The only answer is to stick to the current workflow until some forge provide an equivalently first-class e-mail interface. New participants just have to get used to it. IMO. Nico --
