Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why kernel development still uses email (2016)

lwn.net

Post reply on HN
Print view View original

11–20 of 97 posts

Re: Why kernel development still uses email (2016)

#11

Post by SubiculumCode »

pmoriarty wrote: post #8
TazeTSchnitzel wrote: post #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.

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…

Can we do that with a chat system? Because Slack threading is just inadequate, imo.

Re: Why kernel development still uses email (2016)

#12

Post by u801e »

carussell wrote: post #7
TazeTSchnitzel wrote: post #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.

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, howev…

> On the other hand, the unthreaded approach can help keep the discussion focused and tight.

Or that earlier posts get lost because no one actually sees them. With threaded discussion, if one subthread has gone off-topic, you can always collapse or kill that subthread.

And your point doesn't always hold true. For example https://github.com/torvalds/linux/pull/17

Re: Why kernel development still uses email (2016)

#13

Post by Sir_Cmpwn »

I've been working on a side project to bring the best of both worlds. It aims to provide git repository hosting, issue tracking, continuous integration, and mailing lists to organize efforts. But I'll also be providing web tools for submitting and reviewing patches that provides a workflow familiar to GitHub users, but backed by mailing lists.

If anyone is interested in getting involved in the closed alpha for this software, my email's in my profile. Hit me up!

Re: Why kernel development still uses email (2016)

#14

Post by carussell »

u801e wrote: post #12
carussell wrote: post #7

Earlier quoted context omitted.

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, howev…

> On the other hand, the unthreaded approach can help keep the discussion focused and tight. Or that earlier posts get lost because no one actually sees them. With threaded discussion, if one subthread has gone off-topic, you can always collapse or kill that subthread. And your point doesn't always hold true. For example https://github.com/torvalds/linux/pull/17

> With threaded discussion, if one subthread has gone off-topic, you can always collapse or kill that subthread.

This is a social problem. I deliberately added a disclaimer about the tendency for things to turn to crap if you tolerate it.

I don't know what this is supposed to mean:

> And your point doesn't always hold true. For example https://github.com/torvalds/linux/pull/17

Re: Why kernel development still uses email (2016)

#15

Post by u801e »

IncRnd wrote: post #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.

I've always wondered why newsgroups aren't used instead of email. They pretty much have the same advantages of email and they're far better in terms of searching archives compared to email. Web interfaces for searching email list archives are painful to use. If it wasn't for services like gmane (and later public-inbox), it would be very difficult to view archives of those lists.

Re: Why kernel development still uses email (2016)

#16

Post by leeoniya »

TazeTSchnitzel wrote: post #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.

i'm implementing a webmail app as we speak (from the bottom up). my immediate thought was "wtf are 'conversations', gmail? of course i want threads!".

then i started actually handling the raw email messages. i got threads working pretty well but noticed frequent rendering issues and digging into the cause. my conclusion is, email threading is mostly a pipe dream; it can only be done properly if you have a view of the entire conversation (as is the case with centralized forums/message stores like HN).

the 'References:' header only represents the message ids of any particular branch up to the root. if you try turning a number of messages with the same root into proper threads, you quickly discover missing branches, partial branches/holes, missing leaf nodes, etc. If your knowledge of a thread starts with a message forwarded to you, no thread is possible (even though one clearly exists as indicated by the References chain in the header!). side-conversations that happen (selective replies, cc/bcc), additional fwd/reply chains are all invisible to you. sadly, an incomplete thread view is an extremely common thing (at least in my inbox/sent of ~15k messages).

the client can only thread the actual raw messages it has; those simply quoted in any replies or forwards (which established the Reference chains) don't count. the only commonality you have is knowing the root message id and the timestamp for ORDER BY. everything in between, you may or may not have to reconstruct a partial view of the thread...and each user will have a different view of that thread based on which parts they've been party to.

the threading that i did get working was nice, but not as useful as a bulletproof solution would have been. unfortunately, i don't believe that's possible with email.

i now understand why gmail does flat convos.

Re: Why kernel development still uses email (2016)

#17

Post by nextos »

pmoriarty wrote: post #8
TazeTSchnitzel wrote: post #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.

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 surpasses Gmail). Plus super quick search.

I think it could become a killer application for Emacs (the other two now are org-mode and Magit IMHO).

However, there's no good tooling to keep Notmuch in two-way sync with maildirs right now. Everything works based on tags, which is incredibly flexible, but there should be some tooling to implement logic that allows moving mails around based on their tags, so that the remote IMAP store gets tidy.

People usually rely on scripts for simple use cases, which is fine albeit a bit hacky. Some DSL that resembles Sieve, but implemented in ELisp would be cool.

Re: Why kernel development still uses email (2016)

#18

Post by u801e »

carussell wrote: post #14
u801e wrote: post #12

Earlier quoted context omitted.

> On the other hand, the unthreaded approach can help keep the discussion focused and tight. Or that earlier posts get lost because no one actually sees them. With threaded discussion, if one subthread has gone off-topic, you can always collapse or kill that subthread. And your point doesn't always hold true. For example https://github.com/torvalds/linux/pull/17

> With threaded discussion, if one subthread has gone off-topic, you can always collapse or kill that subthread. This is a social problem. I deliberately added a disclaimer about the tendency for things to turn to crap if you tolerate it. I don't know what this is supposed to mean: > And your point doesn't always hold true. For example https://github.com/torvalds/linux/pull/17

>> And your point doesn't always hold true. For example https://github.com/torvalds/linux/pull/17

> I don't know what this is supposed to mean

What I linked to is an example of a discussion that didn't stay focused or tight despite the fact that it's not threaded.

Re: Why kernel development still uses email (2016)

#20

Post by harrygeez »

nextos wrote: post #17
pmoriarty wrote: post #8

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…

Have you tried mu4e?
Post reply on HN