Why kernel development still uses email
1–10 of 152 posts
Re: Why kernel development still uses email
#2[deleted]
Re: Why kernel development still uses email
#3I like to think that Linux kernel developers master most of the tools they use, especially maintainers who have power to accept patches.
From my own perspective and in different contexts, I can tell that email can be as efficient as it can be inefficient and that depends mostly on its users.
Re: Why kernel development still uses email
#4When I was at Google, gerrit was indeed used internally. Things may have changed in the last 18months, but moving off the old tool to Gerrit was such a huge project that I'd be surprised if they'd moved on to something else.
Re: Why kernel development still uses email
#5I find the idea that a technology should be replaced simply because it is old to be very irksome. Those developers out there blindly contributing to the trend of replacing "tried and true" with "new and shiny" really need to take a step back and gain some perspective.
Email works great for the vast, vast majority of users.
Re: Why kernel development still uses email
#6The number of systems we have created to try and move collaboration off of email is hilariously large.
Between email and lisp, is there any other system that you can find in any sufficiently large system?
Re: Why kernel development still uses email
#7I think it's worth adding, in the age of git sending patches by email is easier then ever - it definitely shows that git was developed by Linus with the kernel's development in mind. There is literally a `git format-patch` command which spits out a full formatted email (or emails) of your various commits, which can then be sent to a mail client to be edited and sent out. Or even easier, just use git to send the patches as email direct via `git send-email`.
The harder part is touched on in the article - email clients and email servers. All the patches sent to the mailing-list are plain text, and lots of clients or servers either mess with the plain text before sending or after receiving. And with that they also take some configuring to avoid sending attachments as base64 - which will be rejected by the kernel. Gmail thankfully doesn't mess anything up on the sever side, but the web client wraps your email to 80 characters per line making it unusable. Because of the above issues, using a separate mail client is essentially required, and setting them up can be annoying and there aren't really tons of them to choose from. I personally use `mutt`, but I can definitely understand why some wouldn't want to bother.
Re: Why kernel development still uses email
#8So I get and agree with what he's saying about how GitHub duplicated email, but as a millennial who uses Vim, I find GitHub much more intuitive and useful than sending patches via email. In general, I disagree with the issues he has with GitHub - most of them are wishy washy disagreements that could easily be solved by adding things to GitHub or using a chrome extension.
IMO the only real, logical reason they need to keep using email is "Email works just as well as GitHub, and we've already been using email, so we might as well continue using it." Which is a good reason on it's own - there's no reason to try and come up with problems with GitHub. (Again, not saying GitHub is perfect, but I don't think the reasons he gave were particularly valid.)
Re: Why kernel development still uses email
#9I find the idea that a technology should be replaced simply because it is old to be very irksome. Those developers out there blindly contributing to the trend of replacing "tried and true" with "new and shiny" really need to take a step back and gain some perspective. Email works great for the vast, vast majority of users.
While I agree, the opposite is also an issue. Developers which either look down upon anything new as "pointless" or in some cases actively try to stop improvements.
Looking at the kernel dev system, it works great, but it has its share of problems. I've never even thought about contributing to the kernel because of the work involved to just submit a patch, that process can be improved.
Making it easier for newcomers, and updating some of the workflow to be more aligned with current tools could really help.
Re: Why kernel development still uses email
#10I think it's worth adding, in the age of git sending patches by email is easier then ever - it definitely shows that git was developed by Linus with the kernel's development in mind. There is literally a `git format-patch` command which spits out a full formatted email (or emails) of your various commits, which can then be sent to a mail client to be edited and sent out. Or even easier, just use git to send the patch…
Outlook loves messing with messages. "Detecting and removing" extra line breaks is one of its features