Live data from Hacker News

Why kernel development still uses email (2016)

lwn.net

1–10 of 97 posts

Re: Why kernel development still uses email (2016)

#2
It doesn't make sense for large projects to move to other systems. Control is lost of the history, which automatically disqualifies any platform. Using services others than e-mail will also entail a revamp and move to a different service every few years.

Email is a far lower cost and more reliable medium most other methods.

Re: Why kernel development still uses email (2016)

#3
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.

Re: Why kernel development still uses email (2016)

#7

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.

On the other hand, the unthreaded approach can help keep the discussion focused and tight. There are few things worse than setting out to get some work done and having to wade through a bunch of comments to find the meat. In the age of Bugzilla, if you wanted to discuss something related, you'd open up a new bug. You'd string things together with a tracking (meta) bug if you liked. This Bugzilla-style workflow, however, doesn't accommodate the stuff that you wouldn't feel you should open a bug for. That's a feature.

Like so many other things, though, this only works if you enforce it. It's pretty horrifying what the GitHub generation tends to think passes for acceptable on bugtrackers, for example.

Re: Why kernel development still uses email (2016)

#8

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 that web forums have yet to catch up on:

- kill files[1] (which you can use to filter out unwanted articles/mails based on content or metadata such as subject, user, etc)

- scoring

- user-configurable anti-spam filtering or other "intelligent" filtering (such as bayesian filtering not just for spam/ham, but for interesting/unintersting content)

- tagging not just on a site-wide level but at the client level so each user can tag messages/articles the way they make sense to them

- other advanced filtering and scripting based on any of the above

Web-based forums are just incredibly primitive compared to this many-decade-old technology.

[1] - https://wikivisually.com/wiki/Kill_file

Post reply on HN