How about using Discourse? I think it scales well. Would love to hear your experience with this.
Why kernel development still uses email (2016)
21–30 of 97 posts
Re: Why kernel development still uses email (2016)
#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 extrapolate that Google should switch to an internal SMTP project management system layered on top of Perforce because "email is faster than any of the alternatives". Same for other companies with high commit rates to their source repos like Microsoft and Facebook.
Since Linus & Linux community never did an A-vs-B experiment of email vs open-source-JIRA-clone as a project workflow, I think we can only safely say that email works best for a disparate group of volunteers with different employers. Email is the lowest common denominator that everyone could agree to use.
You couldn't get 4000 opinionated developers to agree to use an open-source JIRA-clone or MS-Team-Foundation-clone or some other ALM[2]-in-the-cloud.
Therefore, listing advantages of email clients such as "threaded tree views" etc is actually hiding the underlying reason email-as-workflow works for Linux. Email isn't about "throughput"; it's "acceptance".
[1] https://www.wired.com/2015/09/google-2-billion-lines-codeand...
[2] https://en.wikipedia.org/wiki/Application_lifecycle_manageme...
Re: Why kernel development still uses email (2016)
#23Earlier quoted context omitted.
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?
I have spent a decade running mutt, a year running Gnus and a few months running mu4e before switching to notmuch on Emacs.
Mu4e is fine, but I found the interface slightly slow and awkward compared to notmuch. Notmuch's interface is really really good and quick.
Mu4e doesn't ignore underlying folders, which is cool if you have a very simple workflow. It's also superior to notmuch in the sense tags are stored in message headers, so they can easily be sync'ed across clients.
Re: Why kernel development still uses email (2016)
#24One 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…
> 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.
If you buy Reddit gold which makes Reddit to highlight posts that are new since you last time viewed the discussion, then Reddit becomes almost as good as NNTP clients were 20 years ago.
Re: Why kernel development still uses email (2016)
#25Earlier 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…
Can we do that with a chat system? Because Slack threading is just inadequate, imo.
I'm trying to solve this right now with eul[0]. It's not an easy task.
[0]: https://eul.im
Re: Why kernel development still uses email (2016)
#26>, 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…
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.
Re: Why kernel development still uses email (2016)
#27For 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.
Re: Why kernel development still uses email (2016)
#28For 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.
HN doesn't like to be reminded that this is an echo chamber. Dissent is not permitted. Interrupting the circle jerk is not permitted.
Re: Why kernel development still uses email (2016)
#29Ironically enough, Google actually does use Gerrit for their own kernel development.
Re: Why kernel development still uses email (2016)
#30>, 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…
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 single employer. (If you're a single company employing all 4000 of Linux kernel programmers, you could impose an ALM tool be mandatory for code reviews, assigning work, tagging bug reports, etc.)
Discussing positive bullet points of email ... even though each bullet point is true actually obscures the underlying reason the devs won't use an ALM.