The other guy got downvoted, but... isn't there really some tooling to help with this? Some standardized way of actually sending/reviewing the e-mails?
sourcehut has some GUI around it (that I never actually used). I heard that there is some local terminal thing around the e-mail git flow...?
One thing I like - in theory - is how decentralized/federated it all is. E-mail is the original decentralization/federation! But I never had to actually use it.
There is Patchwork which can help with managing the review workload and can also provide some CI feedback, some subsystems use that with some succcess, other's don't. It's not really something an individual can adopt so if you're working in an area that doesn't use it you're out of luck.
There is also Patchew which I've never tried.
But overall everyone just has their own individual pile of shell scrips and mail client macros.
Why would you expect there to be a standardised set of tools used by the largest distributed project in the world? Do you think that this would be possible to enforce globally in a way that makes everyone happier to contribute?
You mentioned two tools that are used by some subsystems. b4[1] is another one, and more are listed here[2]. So there _is_ tooling around it that works for many people. It's just not your preferred choice of tooling, which is... fine.
The fact that email is the lowest common denominator seems like a good thing to me. It allows everyone to use their tools of choice. As long as you can send and receive email, you can contribute. How you decide to integrate that into your development process is up to you. If you can't be bothered to setup a workflow from scratch, then you can adopt someone else's. I'd much rather have this choice, than be forced to use Gerrit or GitHub or whatever else.
I use b4, it largely solves sending code. It doesn't help with reviews though. (b4 shazam makes the manual application of patches to prepare a git-range-diff a bit easier but it's still basically a half baked process. It's fundamentally harder to to review patches than to review Git commits, a few thousand lines of Python won't make that reality go away).
> As long as you can send and receive email, you can contribute.
Sending and receiving email has so many barriers! The Linux Foundation literally has to manage a mail server that people who can't get access to a working mail setup can use! Saying that email is a sensible lowest common denominator is crazy. The reality of it is that the kernel community is majorly dependent on GMail and GMail isn't even a good mail service for the job!
Using a git forge is dramatically easier to use and easier to set up, host and maintain.
However, AFAIK there isn't a forge that exists today that can actually meet the kernel's needs though. Switching to one would be a significant project. (But if the core maintainers wanted it, it would be very feasible).
> It's fundamentally harder to to review patches than to review Git commits
I'm not familiar with kernel development, but after you pull the patches locally, can't you simply review the commits via `git diff` or with whatever viewer you use? This is how I often review code when using GitHub. I only use the GH interface for sending my comments, which is what email in the kernel workflow is for.
The only thing a web-based tool is helpful for is for grouping discussions, and being able to reference or find them later. This might be more tedious with typical web-based email UIs, but most offer some kind of threading and search support, so it can't be that bad.
> Sending and receiving email has so many barriers!
Email has many problems, but I don't see barriers to using it as one of them. There are literally thousands of providers to choose from that could be suitable for sending and receiving patches.
> The Linux Foundation literally has to manage a mail server that people who can't get access to a working mail setup can use!
linux.dev is not managed by the Linux Foundation but by Migadu. It's only offered as a convenience service for people on corporate networks who have no control over their email. They could just as well choose to use another provider.
> Using a git forge is dramatically easier to use and easier to set up, host and maintain.
You contradict this right in your next sentence. You're right that maintaining a centralized system at this scale would be a daunting task. Email being decentralized avoids this problem altogether.
The thing is that a "forge" provides several loosely-related services.
Sharing code is a basic one that Git already does quite well over HTTPS and SSH. What I don't understand is why the patches simply aren't shared this way instead of using email as the medium. The problems outlined in the original article are very real. Kernel development could follow a similar suggested model where URLs to pull from are shared instead, while keeping email strictly for reviews and discussions. This way everyone would be free to choose where they want to host their fork, and maintainers can simply pull from it. But I digress...
The other things forges are used for are code reviews, CI, bug tracking, planning, etc. It's debatable how helpful any of these services are, and many developers would have their own preference. You might like Gerrit, but that's not a universal opinion. And I think most developers would agree that code reviewing in GitHub or Gitlab is painful. If it was up to me, I would choose a tool like git-appraise instead, but I'm stuck with GitHub because that's what the teams I've worked on have preferred.
So my point is that email is likely not the best choice for this, but it's a reasonable one that's flexible enough to be usable by anyone. Forcing any other tool on everyone would likely displease an equal or greater amount of contributors, while also introducing maintenance and reliability problems.
sourcehut has some GUI around it (that I never actually used). I heard that there is some local terminal thing around the e-mail git flow...?
One thing I like - in theory - is how decentralized/federated it all is. E-mail is the original decentralization/federation! But I never had to actually use it.