@mupuf
It's complicated. 🥴
But Linus recently indicated that it's maybe time to move on from email. We'll see.
Maybe the DRM developers should talk more about their solution and how it works really well for them, then maybe other kernel subsystems might follow suit.
I mean, even git is kinda still optional and one major subsystem until maybe two years ago was sending all their stuff as a patch-bomb to Linus.
This would be a great development for new contributors!
Mailing lists aren’t that hard if you have the right tools. For most people, it’s just a few lines of configuration. But there are a lot of hidden tools for emails that you simply don’t get with PR workflow. You’ll get very attached to them once you start. That’s the reason why many kernel devs are so attached to emails.
What is happening here? Where is the patch? Where at the comments on the patch? Is each email a commit?
The are enormous quotes and “squash it into this function”, then then entire quote is quoted again (scroll, scroll, scroll), “OK, I’ll squash it”.
Then it seems like somebody has hard-wraps (probably at the archaic 80 characters because they still work on a 4:3 CRT) which change the format of everything mentioned before.
There is so much visual noise in mailinglists which is cleaned up significantly by source forges. You don’t have to read the same quoted code every single time somebody comments on that bit of code in the thread. Then there’s the forever repeated To, From, CC, title and other stuff. The clutter is immense.
Even if they decided to keep mailinglists, they could at least put on a better UI, but the next problem will be people who don’t conform (either because they’re new, forgetful, etc.). It’d be like trying to get people to write perfect XML each time and the UI could break in amazing ways depending on how the person formats their response.
I grew up with shitty UIs (windows 3.1 and windows 95), but mailinglists are even worse.
My fav ones are b4 and lei - both backed by a system called public-inbox. Linux kernel Lore is a public-inbox instance. There are other tools too - like patchwork. B4 and Lei, for example make working with patch series a breeze. You can also do things like compare different versions of the same branch - something that Github PR model is sorely lacking in.
What is happening here? Where is the patch?
That’s what public-inbox and patchwork are for. Lei is especially useful with public-inboxes. If you are a bit more established, there are tools like notmuch and aerc that can make it even more easier.
Is each email a commit?
Yes, that’s the idea. But more specifically, each email is a patch. Usually, a single patch is a refined commit with a full feature that you get after proper rebasing to weed out experimental code, mistakes, etc. A single submission is often just one or a handful of patches.
Where at the comments on the patch?
You don’t deal with patches and emails manually that deep. You only need to have a rough awareness of the location of the patches (lei, notmuch, etc help you with this awareness). Code review mails and discussion mails are often threaded and intertwined with a series of patches. Threading actually helps you to follow the correct flow of discussion. Think of mailing lists as PR, Issue tracker and discussion forum rolled into one. You wont be hunting patches in this haystack. That’s the job of the tools - they extract the correct series of patches in the right order, ready to be applied. Some can even alert you to the presence of newer revisions of the patch series. (I’m not even sure how far this goes - I haven’t tried patchwork yet). There is actually a lot of automation involved.
but mailinglists are even worse
Even if they decided to keep mailinglists, they could at least put on a better UI
Frankly, here is the problem! All the other problems you mentioned boils down to this. The thing is - Github and Mailing lists deal with the same kind of data - with the latter being more transparent. But the mailing list interfaces are god-damn awful. But honestly, it doesn’t have to be like that. I believe that with some proper UI design, mailing lists can offer an experience that’s at par or even better than GH PRs. All the noise and clutter you mentioned doesn’t need to be there. The tools make all the difference. Webmail clients like Gmail just butcher the mails. But it’s already much better when you have a text-only threaded mail client. I believe people hate email workflow just because of how badly its interface is designed.
Webmail clients like Gmail just butcher the mails.
Too true. I tried using mailinglists with gmail nearly a decade ago and regretted it.
I believe people hate email workflow just because of how badly its interface is designed.
And the amount of tools you need to know of in order to have a bearable experience. b4, lei, patchwork, notmuch, aerc, … sounds like a lot of work and knowledge needed just to be able to use a mailinglist. Source forges have an intuitive interface that allow even beginners to contribute without setting up a bunch of tools.
IMO any project looking for contributors and using mailing-lists is either stuck in their ways, targeting a specific group of people, or both. Mailing lists don’t bring the boys to the yard. Hopefully the linux kernel maintainers learn this some day.
Mailing lists aren’t that hard if you have the right tools. For most people, it’s just a few lines of configuration. But there are a lot of hidden tools for emails that you simply don’t get with PR workflow. You’ll get very attached to them once you start. That’s the reason why many kernel devs are so attached to emails.
I’m curious, what tools are you talking about?
I’ve never had a good experience with mailinglists and find them impossible to navigate. For example: https://lore.kernel.org/linux-media/20231222045228.27826-1-jason-jh.lin@mediatek.com/T/#m1f842978210ac8ef1a4d9b7f7b0206cf7fdf1964
What is happening here? Where is the patch? Where at the comments on the patch? Is each email a commit?
The are enormous quotes and “squash it into this function”, then then entire quote is quoted again (scroll, scroll, scroll), “OK, I’ll squash it”.
Then it seems like somebody has hard-wraps (probably at the archaic 80 characters because they still work on a 4:3 CRT) which change the format of everything mentioned before.
There is so much visual noise in mailinglists which is cleaned up significantly by source forges. You don’t have to read the same quoted code every single time somebody comments on that bit of code in the thread. Then there’s the forever repeated To, From, CC, title and other stuff. The clutter is immense.
Even if they decided to keep mailinglists, they could at least put on a better UI, but the next problem will be people who don’t conform (either because they’re new, forgetful, etc.). It’d be like trying to get people to write perfect XML each time and the UI could break in amazing ways depending on how the person formats their response.
I grew up with shitty UIs (windows 3.1 and windows 95), but mailinglists are even worse.
CC BY-NC-SA 4.0
My fav ones are b4 and lei - both backed by a system called public-inbox. Linux kernel Lore is a public-inbox instance. There are other tools too - like patchwork. B4 and Lei, for example make working with patch series a breeze. You can also do things like compare different versions of the same branch - something that Github PR model is sorely lacking in.
That’s what public-inbox and patchwork are for. Lei is especially useful with public-inboxes. If you are a bit more established, there are tools like notmuch and aerc that can make it even more easier.
Yes, that’s the idea. But more specifically, each email is a patch. Usually, a single patch is a refined commit with a full feature that you get after proper rebasing to weed out experimental code, mistakes, etc. A single submission is often just one or a handful of patches.
You don’t deal with patches and emails manually that deep. You only need to have a rough awareness of the location of the patches (lei, notmuch, etc help you with this awareness). Code review mails and discussion mails are often threaded and intertwined with a series of patches. Threading actually helps you to follow the correct flow of discussion. Think of mailing lists as PR, Issue tracker and discussion forum rolled into one. You wont be hunting patches in this haystack. That’s the job of the tools - they extract the correct series of patches in the right order, ready to be applied. Some can even alert you to the presence of newer revisions of the patch series. (I’m not even sure how far this goes - I haven’t tried patchwork yet). There is actually a lot of automation involved.
Frankly, here is the problem! All the other problems you mentioned boils down to this. The thing is - Github and Mailing lists deal with the same kind of data - with the latter being more transparent. But the mailing list interfaces are god-damn awful. But honestly, it doesn’t have to be like that. I believe that with some proper UI design, mailing lists can offer an experience that’s at par or even better than GH PRs. All the noise and clutter you mentioned doesn’t need to be there. The tools make all the difference. Webmail clients like Gmail just butcher the mails. But it’s already much better when you have a text-only threaded mail client. I believe people hate email workflow just because of how badly its interface is designed.
Too true. I tried using mailinglists with gmail nearly a decade ago and regretted it.
And the amount of tools you need to know of in order to have a bearable experience. b4, lei, patchwork, notmuch, aerc, … sounds like a lot of work and knowledge needed just to be able to use a mailinglist. Source forges have an intuitive interface that allow even beginners to contribute without setting up a bunch of tools.
IMO any project looking for contributors and using mailing-lists is either stuck in their ways, targeting a specific group of people, or both. Mailing lists don’t bring the boys to the yard. Hopefully the linux kernel maintainers learn this some day.