TechNom (nobody)
Choosing Rust instead of C or C++ for new projects is a rather light decision. But introducing it into or outright replacing legacy codebase with it is a rather phenomenal undertaking. Fish shell was completely rewritten. Linux is introducing it in no trivial way. I wonder if the woes with C/C++ is that bad.
This is an old post and a lot has changed since then. Many of the points in that article are no longer true. Drew himself started a language - hare, for which he is considering Rust style borrow checker to ensure safety. It’s a bit wrong to bash anything based on a half a decade old opinion.
I’m curious, what tools are you talking about?
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.
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.
Torvalds indicated in a recent interview that they’re struggling to find young maintainers. Many people contribute, but few stay around to become proficient enough and take on the responsibility of maintainership. I believe that the email comment was made in this context.
However, I don’t think that many kernel devs including Torvalds are in favour of the Github workflow. He once indicated his strong dislike for it. So the replacement for email won’t be Github - but something just as easy, without sacrificing the quality that the kernel devs need.
Finally, a word is kernel development. Contrary to popular belief, they aren’t hostile to new contributors. Kernel developers have high quality intro material for newbies - including for email workflow. They’re also very considerate and patient with newbies. Even Torvalds who was known for his abrasive style in the past really took that only on experienced developers doing the wrong thing.
I mean, if it’s a one time payment then he has no reasons to regret the decision even if the users dropped off. On the other hand, if he was expecting a recurring royalty from the buyer, then he didn’t think it through.
PS: I’m not justifying his actions in any manner. If a sale without a heads up is deceptive, his last reply was outright indignation. I’m just trying to understand whether he actually regretted it or not.