I've used email-based workflow for a few contributions I've made.
The git-send-email part isn't too bad. It's everything else I have a problem with:
- You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution.
- Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email.
- The flow for "Dealing with feedback" in this tutorial will start a new email thread instead of replying to the existing one. There is a way to reply to an existing thread with send-email, but it is kind of involved since you have to look up the message id of the email you are replying to (which may or may not be easy depending on your email client). And even then, I've had mixed success with it.
- Although I haven't been on the other side of it, it seems like reviewing the patch would be somewhat difficult without additional tooling. Especially comparing new versions dealing with feedback to the original version.
- Again, I haven't been on that side of it, but it seems like applying the changes from an email would be a bit of a pain compared to just pressing "merge".
- You can run into issues if your lines of code are more than 78 characters long. I used git-send-email to send in a patch once that had this, but the email client of the receiver couldn't handle long lines, so I had to resend it with the patch as an attachment.
- Some mailing lists require you to subscribe before you can send a patch. And if the list is pretty active, that can flood your inbox. See my first point.
You have some points, for some I do think it isn't as bad as you write. FWIW, some comments inline.
> - You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution.
You can use tools like public-inbox or lei, the former is hosted for bigger projects on https://lore.kernel.org/
And sure subscribing for a drive by submission is rather overkill, but if one contributes more than a few patches, 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. List have a dedicated List-Id header, so one can easily filter them in a targeted way.
What I want to convey actually is, that yes, there can be improvements made here, but doing so isn't impossible just because the message medium is decentralized mail vs. a centralized HTTP API.
- Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email.
Hard disagree on that being the general case. Even getting Thunderbird to send plaintext is simple and only one setting, and there are mailers like aerc [0] or neomutt that are really well suited for an integrated mail + apply + review setup.
But sure, there are some bad apples, especially most web mailer.
> - The flow for "Dealing with feedback" in this tutorial will start a new email thread instead of replying to the existing one.
Yes, for sending a new revision this is highly wanted – please do NOT send new patch revision to the same thread, that just crowds review and adds nothing. Simply add a changelog to the previous revision in the cover-letter and/or in each patch, i.e., after the message, below "--" and before the diff-stat, as there they won't get into git, such changes are meta info relevant for review, not for the git history.
> - Although I haven't been on the other side of it, it seems like reviewing the patch would be somewhat difficult without additional tooling. Especially comparing new versions dealing with feedback to the original version.
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). IMO much higher quality of life than with the classic Git(La|Hu)b forges.
> - Again, I haven't been on that side of it, but it seems like applying the changes from an email would be a bit of a pain compared to just pressing "merge".
No it really isn't, I'm doing that since years a dozen+ time a day, and it is as easy now as it was back then when I started.
If I use thunderbird I got my one directory for it, so I just mark all, save and execute `git am ~/t/aaa/*` in the repo. When I use aerc, then it's even simpler, it has built-in helpers for doing this easily.
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. Also, the interface often loads weirdly, as they manage their own history as a single page app which often gets in a state where button presses won't do much.
> - You can run into issues if your lines of code are more than 78 characters long. I used git-send-email to send in a patch once that had this, but the email client of the receiver couldn't handle long lines, so I had to resend it with the patch as an attachment.
git send-email uses base64 encoding for that, if the mail user agent of your recipient cannot handle that it's like their broswer cannot handle HTTP/1.1, switch that stuff immediately.
> - Some mailing lists require you to subscribe before you can send a patch. And if the list is pretty active, that can flood your inbox. See my first point.
Yeah, sadly sometimes needed for anti-spam measurements, here I agree fully that this isn't ideal, but FWIW, for Git(Hu|La)b I also need to create a account and fork, so it's not exactly zero work there too, but yeah, due to SSO and gaining access to many projects, vs. just one for a subscription that is not really comparable..
The amount of "gotchas" in this process and the tooling required just to use git + email seems insane to me. If it works for you, great, but I don't expect a new hire (experienced or not) to pickup this flow and run with it.
A few comments in-line, but I don't want to "sell" anything to you, so just FWIW.
> The amount of "gotchas" in this process and the tooling required just to use git + email seems insane to me.
The base system is really, really simple, but there are some common rules/guidelines that just help when working together, and those are required for forge based workflows too (or do you like a single commit touching a dozen completely different, unrelated things, or just no info at all in the commit message, or pull request, for why a change was done).
The core thing from this workflow is using `git send-email --to=mailing@list.example.com <commit-revision>`, the rest are a few details, possible slightly intimidating if viewed from a distant, but each separate and easy to master/implement on it's own – and most are a "set up once, be done thing", so not constant work.
> If it works for you, great, but I don't expect a new hire (experienced or not) to pickup this flow and run with it.
As mentioned in another comment: We hired over 15 people in the last year, most of them had no experience with git send-email and mailing list development, but they all accustomed fast and after a few weeks most of them stated they find it nicer (as in simpler, less clutter quicker to do submit own work or review others) - I myself started out over eight years ago at this place, i.e., without much experience in mail based development, and I never ran into bigger problems – on the contrary, this workflow felt like a breadth of fresh air compared to what was I used before (mostly GitHub and GitLab).
Note: this works not only for small to medium, but also is the only way that actually works for the biggest projects in the world (e.g., Linux or QEMU).
Just to be sure: I do not say mail(ing list) based development workflow is Just Perfect™, it sure has its problems and can be improved, and may we get some good web GUIs that tie a few of the components together, currently I see https://sourcehut.org/ as strong contender here.
This "shit" (which take is not much though, most of it you do once and as you're probably already using email, using a good mail user agent will help you in other ways too. And I only wrote that "much" to answer to every point of OP, it's a few lines – attention span really has gone down hill.
And what better system? Git(Hu|La)b et al.? Yeah no, you definitively didn't use either much in a collaborative way to just call them better, besides being centralized locked-in. Or what's actually better there? I'd love to hear actual arguments and experiences from someone collaborating with hundreds of other people on a project on these Labs/Hubs, not some hand waved name-calling that adds exactly nothing.
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.
The git-send-email part isn't too bad. It's everything else I have a problem with:
- You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution.
- Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email.
- The flow for "Dealing with feedback" in this tutorial will start a new email thread instead of replying to the existing one. There is a way to reply to an existing thread with send-email, but it is kind of involved since you have to look up the message id of the email you are replying to (which may or may not be easy depending on your email client). And even then, I've had mixed success with it.
- Although I haven't been on the other side of it, it seems like reviewing the patch would be somewhat difficult without additional tooling. Especially comparing new versions dealing with feedback to the original version.
- Again, I haven't been on that side of it, but it seems like applying the changes from an email would be a bit of a pain compared to just pressing "merge".
- You can run into issues if your lines of code are more than 78 characters long. I used git-send-email to send in a patch once that had this, but the email client of the receiver couldn't handle long lines, so I had to resend it with the patch as an attachment.
- Some mailing lists require you to subscribe before you can send a patch. And if the list is pretty active, that can flood your inbox. See my first point.
- etc.