Live data from Hacker News

Why kernel development still uses email (2016)

lwn.net

31–40 of 97 posts

Re: Why kernel development still uses email (2016)

#31
post #22

>, kernel developers still use email because it is faster than any of the alternatives. Over the course of the last year, the project accepted about eight changes per hour — every hour — from over 4,000 developers sponsored by over 400 companies Compare with Google's ~1875-per-hour from 2015[1]: >, and Google’s 25,000 engineers make about 45,000 commits (changes) to the repository each day. Obviously, we can't extrap…

I got in this same discussion with gregkh on Reddit, and Torvalds in person. Linux development is much slower than many large software engineering firms, because the gatekeeper model has many more integrators and reviewers as a proportion of the members than the "pull request"/ team code review model

Acceptance is certainly part of it, but 8 changes per hour is 8-10 email threads per hour, which is just not that hard to track as an individual, thus no need to change anything. Right now at work on a large (200ish) team, I get cc'd on about the same amount of patches.

Re: Why kernel development still uses email (2016)

#32

One of the best things about email is that, with the right client, you can view discussions as hierarchical trees. That means you can have multiple simultaneous discussions about a topic asynchronously and not lose track of anything. GitHub and the like only work that well when there's maybe one or two things being discussed at once, because there's just a single linear stream of comments.

This is one of the things that web-based forums have yet to get right. Email (and NNTP news) clients from 20 or 30 years ago are far superior in this respect, because they can intelligently deal with threading and folding. These features alone makes large conversations much easier to deal with than on web-forums. To add to that, email (and NNTP news) clients even from 20 or 30 years ago have other powerful features t…

The problem is we don't have the users from 20-30 years ago either.

Now, even though I and my email client still use threading, much of my incoming corpus does not. Instead, I see a mixture of users who break every thread (no In-Reply-To headers, ever), users who cannot comprehend subject metadata versus first line of message, and users who use the most recent few screens of activity as an address book, always replying to the end of a thread with a completely unrelated and new topic.

Re: Why kernel development still uses email (2016)

#33
post #6

For 99% of folks outside the HN echo chamber, email works fine. Spam is a problem, but I've never heard or read of anyone who thinks email needs to go the way of the dodo except on this site.

I'm having a really hard time getting my friends to email me. They want me to use awful garbage like FB Messenger or Whatsapp instead.

Re: Why kernel development still uses email (2016)

#34
post #6

For 99% of folks outside the HN echo chamber, email works fine. Spam is a problem, but I've never heard or read of anyone who thinks email needs to go the way of the dodo except on this site.

I have no idea why you're downvoted. Email is great especially because it's an open standard. I don't understand why people expect Linux kernel development to adopt some kind of proprietary platform for communications. I think it's a terrible idea.

On that note, a while back while browsing f-droid i noticed someone working on a email based IM app.

Never mind that "text messaging" in say Japan has been email based since virtually forever, since the SMS standard had issues with Japanese script.

Re: Why kernel development still uses email (2016)

#35
post #17

Earlier quoted context omitted.

This is one of the things that web-based forums have yet to get right. Email (and NNTP news) clients from 20 or 30 years ago are far superior in this respect, because they can intelligently deal with threading and folding. These features alone makes large conversations much easier to deal with than on web-forums. To add to that, email (and NNTP news) clients even from 20 or 30 years ago have other powerful features t…

Exactly. Gnus is a marvelous client because it has really good NNTP and threading support (silencing and automatic scoring) that allows you to cope with gigantic volumes of email. It's a bit sad the code is messy and it's a tad slow compared to other options. Notmuch for Emacs has so much potential to replace Gnus. The interface is incredibly fast and friendly (a classic tree view and a threaded view that IMHO surpas…

Notmuch has potential, but also a bunch of limitations and issues compared to Gnus.

Notmuch doesn't have scoring, it doesn't have BBDB integration, it has no way to get arbitrary message headers from elisp, it only indexes a handful of headers.

I've heard it is possible to use notmuch as a backend for Gnus, to get the best of both worlds.

As for two-way sync, some people have come up ways of doing that, using something like Sieve.

For me two-way sync is not super critical, as I've come to view the webmail interface of my mail provider as just a backup to use in case my laptop dies or something. In all other cases, I'll just use notmuch, for which local tags are enough.

Re: Why kernel development still uses email (2016)

#36

Earlier quoted context omitted.

This is one of the things that web-based forums have yet to get right. Email (and NNTP news) clients from 20 or 30 years ago are far superior in this respect, because they can intelligently deal with threading and folding. These features alone makes large conversations much easier to deal with than on web-forums. To add to that, email (and NNTP news) clients even from 20 or 30 years ago have other powerful features t…

The problem is we don't have the users from 20-30 years ago either. Now, even though I and my email client still use threading, much of my incoming corpus does not. Instead, I see a mixture of users who break every thread (no In-Reply-To headers, ever), users who cannot comprehend subject metadata versus first line of message, and users who use the most recent few screens of activity as an address book, always replyi…

I wish I could reject messages where the subject and body did not correspond.

Or maybe give up and have some sort of manual threading overlay where I could rearrange and add my subject tags for messages..

Re: Why kernel development still uses email (2016)

#38

How about using Discourse? I think it scales well. Would love to hear your experience with this.

I find Discourse absolutely horrendous. Discourse mailing-list mode is a tack-on at best, and the formatting you get in mail notifications basically require you to be online to visit the link. And the gamification is also a huge put-off.

Web forums made us forgot how far we came with NNTP years ago. Even the shittiest NNTP could do subthread splitting, hiding and scoring. Handling hundreds of messages per day was easy. The convenience of doing-it-all under one powerful client was massive.

You can still do that with mailing lists, as long as it's not as badly managed as forums-with-a-wanna-be-mailing-list-mode addon as Discourse is.

Re: Why kernel development still uses email (2016)

#39
post #30
post #26

Earlier quoted context omitted.

Its not comparing the same thing I think, commits to a repo and diffs sent over email, and even if it was, its not really the same thing anyway... Kernel development seems to progress fine, I'm pretty sure if there was a problem, Linus would have made some effort to change it, just like the whole source control thing that ended up becoming Git.

>Kernel development seems to progress fine, I'm not claiming that there's a bottleneck in kernel commits. (I'd guess human code reviews checking quality is the ultimate bottleneck.) I'm saying that using emails as "building blocks to reconstruct an pseudo ALM" instead of using an actual special-purpose ALM -- is the only realistic workflow that would be accepted by the disparate Linux community who don't work for a s…

It seems like that argument cuts both ways; what about developers who refuse to use the email-based process?

Re: Why kernel development still uses email (2016)

#40
post #22

>, kernel developers still use email because it is faster than any of the alternatives. Over the course of the last year, the project accepted about eight changes per hour — every hour — from over 4,000 developers sponsored by over 400 companies Compare with Google's ~1875-per-hour from 2015[1]: >, and Google’s 25,000 engineers make about 45,000 commits (changes) to the repository each day. Obviously, we can't extrap…

> Compare with Google

isn't google's situation a monorepo composed of many distinct projects? there doesn't seem much utility in the comparison.

> Email isn't about "throughput"; it's "acceptance".

this seems to be the similar, in the other direction. using (or not) an alm in an organization isn't about "throughput", it's about "accepting" a company's policy assertions.

Post reply on HN