Live data from Hacker News

Why kernel development still uses email

lwn.net

31–40 of 152 posts

Re: Why kernel development still uses email

#31

As always, it's worth pointing out that this is just about the Linux kernel. Different scale, different developer community, different code structure, different testing/CI methodology (i.e. practically none) than just about every other project out there. Email works for them - great. Other things work for other people - also great. Theirs is one interesting data point, but that's all it is.

>As always, it's worth pointing out that this is just about the Linux kernel. Different scale, different developer community, different code structure, different testing/CI methodology (i.e. practically none) than just about every other project out there.

Eh? Patches on mailing lists is the "traditional" way for open source projects to operate. Many projects "still" do things this way - indeed I wish more projects did, for the reasons outlined in this article!

Re: Why kernel development still uses email

#32
post #16

"Some systems, like Outlook, will uniformly corrupt patches; as a result, companies doing kernel development tend to keep a Linux machine that they can use to send patches in a corner somewhere." Isn't a Linux desktop also convenient for the development itself?

I developed a series of patches for the RPi kernel fork. I use the Pi headless, and generally access it from a Windows machine.

I never tried to send those patches upstream - and the Pi fork uses Github for such things - but I'm entirely confident that if I tried to paste those patches into an email client somewhere along the line, I'd get an upstream maintainer pointing out that magical line breaks blew something up somewhere.

Re: Why kernel development still uses email

#34

I 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

I remember reading that when Microsoft started contributing some code to the Linux kernel (to support Hyper-V mostly) they had to run their own Linux server in house so they could send properly formatted emails for their patches, since they had no way to send email that wouldn't be messed-up by their Outlook servers.

Re: Why kernel development still uses email

#36
post #17

Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard with many implementations on both the client and server. It is exceptionally easy to manage email. Many servers have great systems for categorizing emails and storing them long-term. Email is fast. Everyone has one. There is this weird myth that Email magically kills productivity while Slack and GitHub don't. I never underst…

It's apples and oranges. Email, phone, IRC/Slack/Lync/Hipchat/Discord. They all have their own purposes. I don't think many companies are trying to replace email; just provide an alternative for times when email would be unnecessary and bulky.

I like to think of email as the "ledger" or repository, while your IRC alternative is your working branch.

Re: Why kernel development still uses email

#37
post #8

So 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…

I don't really feel that you being a millennial or using vim is relevant.

I have no idea how you would go about getting github to implement whatever functionality is desired and even so would come with the following disadvantages

-- Requiring a chrome extension limiting people to using chrome + a singular website vs any email client under the sun

-- wouldn't work offline

-- Presumably it would be more challenging for sight impaired individuals to use a js heavy website vs their email. They stated they had existing contributors who were so impaired.

-- Since people still presumably do a lot of discussion via email it would mean using at minimum github AND email some of which would refer back and forth to other discussions.

-- Relying on github would require tying free software infrastructure to a single non free software tool. Recalling bitkeeper this didn't go well last time.

-- Hosted github costs additional money.

-- The primary and perhaps only benefit would be making it easier for people to come in off the street and drop patches with minimal effort but this would actually cost effort to manage and the kind of individual who can't or likely wont figure out how to use existing infrastructure may not be an optimal contributor in any case.

Basically your solution involves not only effort to create tools that don't exist, the cooperation of a third party, but the end result would almost certainly be objectively worse in a number of ways.

I feel like you didn't really address any of the things the actual expert on the matter said and just hand waved his entire argument away.

Re: Why kernel development still uses email

#38
post #17

Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard with many implementations on both the client and server. It is exceptionally easy to manage email. Many servers have great systems for categorizing emails and storing them long-term. Email is fast. Everyone has one. There is this weird myth that Email magically kills productivity while Slack and GitHub don't. I never underst…

Email is tremendously useful, and whatever replaces it should borrow from those useful bits. It also has numerous problems. Some are listed in the article: 1. Clients (and some servers) mangle email. You can't be assured that what you send is what someone else will receive. I blame the clients and servers here, but ... 2. Privacy. This has become among the biggest downsides. Whether it's data-in-flight or data-at-res…

I think you're trying to have your cake and eat it too. Wouldn't a global directory of email addresses be the antithesis of privacy?

The greatest difference between email and all of today's proprietary alternatives is that your email identity doesn't need to be vetted by any central authority. Of course this makes spam harder to deal with, but it's part of the cost of decentralization and one that we must learn to deal with. Fortunately, most of the email services I use are pretty good at filtering spam, as well as making sure that my emails don't get marked as spam by other email services.

Re: Why kernel development still uses email

#40
> "On the other hand, GitHub does not scale to larger projects. He pointed at the Kubernetes project"

It seems according to this, that Github is fine for a project until it scales to such a size as you need an alternative.

So even this is agreeing that small projects should start with Github.

It would be useful to know the lower bound of users/developers at which point you need to switch to a more flexible system like email.

Post reply on HN