| > You can use tools like public-inbox or lei Maybe I'm missing something, but those seem like they are for searching mailing lists. I'm not sure how they solve the problem of, getting notified for threads I care about, but not for all of the other ones I don't. > setting up a filter is to easy with mailing lists that I don't think one can just hand wave that away as an "unreasonable" solution. Ok, so suppose that there is a patch submitted to fix a bug I care about. I don't want to reply, because I don't have any new information to add, but I want to know once the patch is merged. Yes, it is possible to subscribe to the mailing list and create an email filter, assuming that I know enough about SMTP headers, and i am already familiar with and use a powerful mail client, and only use a single client that I have those filters on. Or have a mail service with very powerful filtering functionality (unlikely). But I wouldn't exactly call it easy. > List have a dedicated List-Id header, so one can easily filter them in a targeted way. That's useful for putting all emails from a list in a folder, but doesn't help if you are only interested in a small subset of the emails for any given list. > because the message medium is decentralized mail vs. a centralized HTTP API. well, my biggest problem is that the granularity of subscription is far too coarse. It doens't really have to do with being centralized or not. > there are mailers like aerc [0] or neomutt that are really well suited for an integrated mail + apply + review setup I've tried using aerc and neomutt. I don't doubt that once you have them set up and have learned how to use them, they work well for this flow, but the learning curve is pretty steep. And they don't work as well for some of my non-development email. > But sure, there are some bad apples, especially most web mailer. In other words, the most popular email clients. > please do NOT send new patch revision to the same thread, that just crowds review and adds nothing So you just lose all the context of the previous review? And you review the whole thing from scratch? As a reviewer my preferred workflow for changes to a patchset is to receive incremental commits that build on the previous changes, then squash them before merging. > I have reviewed lots of patches via mailing list, it's really nice and depending on the patch one can review directly inline or apply (save + `git am`, or directly `git am` depending on your mailer). How do you handle commenting on large patches that change many files? I imagine in such cases you would `git am` the changes and view the diff using your git diff tool of choice, file by file. But then if you find something you need to comment on, you would have to go back to the email client, and search through the large amount of text to find the appropriate line to comment on. That seems rather tedious and disruptive to me. > Here I can manage simple conflicts easily (e.g., using three-way-merge) on GitHub conflicts are a bigger PITA and need lots of manual intervention from me or waiting on the submitter, meh FWIW when I deal with conflicts in github, I don't use the UI. I pull the branch of the PR, merge or rebase, resolve the conflicts, and then if the submitter allows, push the changes back up to their branch, or make my own branch. Then I wait for CI to finish before merging the changes post-conflict-resolution. To be fair, I am somewhat biased, since I have a lot more experience with the Github flow than mailing list flows. But I would also like to learn how the mailing list flow works in practice, in part so that I can contribute to projects that use it. It seems like there must be tooling and practices that I am ignorant of, but websites like the OP usually don't go any deeper than explaining how to use git send-email and telling you to use a better MUA. |