@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!
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.
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.