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

51–60 of 97 posts

Re: Why kernel development still uses email (2016)

#51

Post by bassman9000 »

jasode wrote: 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…

4000 developers sponsored by 400 companies.

Let than sink in. It's not only 4000 opinionated devs. It's, potentially, 400 completely different organizations; 400 management layers on top; 400 different priority sets; devs in every time zone; etc. Google is just 1 company (a dozen, if you want to break down Alphabet).

It's amazing that they manage to get 8 changes an hour, and still be one of the most successful open source, and software project in general.

Why changing the system?

Re: Why kernel development still uses email (2016)

#52

Post by jasode »

abiox wrote: post #49
jasode wrote: post #46

Earlier quoted context omitted.

>using (or not) an alm in an organization isn't about "throughput", it's about "accepting" a company's policy assertions. I don't think that equating it from the reverse direction works. Here's why: Using the article's count of ~4000 developers, let's consider all software companies that employ 4000+ developers as part of a "natural experiment"[1]. This includes companies and organizations like MS, Facebook, NASA, SA…

> Since companies have every incentive to develop software with cost-efficiency and velocity, they will want to use the best workflow possible. in the abstract these are generally viewed as or presumed to be positive, but the pressures and objectives of a business can be rather complex and other things will often compete for finite resources. having worked in a number of large organizations, the waste and inefficienc…

>having worked in a number of large organizations, the waste and inefficiencies one can find is absolutely staggering.

Sure, I agree this is true in a general sense (Dilbert cartoons, Peter Principle, etc). However, for things like choosing technology to help with market superiority, companies (especially software engineering companies) will eventually gravitate to something better.

We could argue that companies are "inefficient" for not embracing remote work-from-home instead of open offices, etc. (general inefficiencies). But, even badly run companies don't insist on using inferior floppy drives instead of USB drives or wireless network file transfers. Yes, a law firm might limp along with an 15-year old version of Microsoft Word 2000, but a software engineering company will not. (technology inefficiencies)

> introducing process and bureaucracy isn't always a win.

The Linux dev community also has process & bureaucracy. See my previous link for the strict and precise formatting rules to submit kernel patches in emails. That's process. Just because it's not in a web form with fields doesn't mean it's not "process". They're just using emails as the workflow for it. (Linus has famously chastised contributors for not following "the rules".) Process & bureaucracy is not bad thing -- its effort just has to match the scope of work being delivered. (E.g. using JIRA for a "hello world" toy program is overkill.) The Linux kernel community seems to have converged on the level of bureaucracy that works for them.

It's interesting that even young YCombinator companies with much less than 4000 employees also don't stay with SMTP email-as-ALM as they get bigger. If email-as-ALM was a better software dev philosophy, there would be a huge arbitrage opportunity to outcompete everybody. Instead, the email-as-ALM fits Linux kernel devs' specific circumstances.

Re: Why kernel development still uses email (2016)

#53

Post by nextos »

pmoriarty wrote: post #35
nextos wrote: post #17

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

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

I ran Gnus with notmuch backend (nnir-notmuch) for many months. It's not very fast as Gnus is not very quick on Maildirs.

Scoring could be quite easy to implement with auto-tagging. Tags are a unifying concept in email. You can implement any custom user logic with tags. What notmuch is missing is a bit of tooling to do this. It'd be cool if this tooling had access to any arbitrary header, as you have pointed out.

I feel I don't need BBDB integration when I have autocompletion based on the email database. That said, there's bbdb-notmuch.el, and I assume other options as message-mode is really a Gnus thing.

I think basic two-way sync is almost always needed. Otherwise you end up with a huge inbox and even if you don't care at all about the remote IMAP store, mbsync calls will start slowing down.

Re: Why kernel development still uses email (2016)

#54

Post by kashyapc »

I split my time between Gerrit-based and email-based projects. While I appreciate Gerrit for its benefits (like the excellent CI integration), I instinctively tend to gravitate towards my email-based workflow that is blazing fast, allows me to work completely offline (once OfflineIMAP fetches email in the morning), and lets me process tons of email / patches.

The said offline workflow (setup with: Mutt, OfflineIMAP, Postfix for local mail queueing, and Notmuch for fast indexing / searching / tagging) gives me unalloyed joy compared to the clickety-clicky, RSI-inducing pain that is Gerrit.

The problems listed in the below email, by Dan Berrangé, about Gerrit are still a bloody pain in the neck for me:

https://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg...

[I learnt 2 days ago (can't find the URL to it; typing from my phone) that Gerrit now allows you to respond via email (strangely the announcement only mentioned the dreaded HTML email). I'm a bit cautious to say "sounds promising" without trying it yet.]

Re: Why kernel development still uses email (2016)

#55

Post by jasode »

marcosdumay wrote: post #50
jasode wrote: post #46

Earlier quoted context omitted.

>using (or not) an alm in an organization isn't about "throughput", it's about "accepting" a company's policy assertions. I don't think that equating it from the reverse direction works. Here's why: Using the article's count of ~4000 developers, let's consider all software companies that employ 4000+ developers as part of a "natural experiment"[1]. This includes companies and organizations like MS, Facebook, NASA, SA…

Or, alternatively, ALMs provide some other kind of value (that is iteration velocity or efficiency) that Linux developers don't care about.

>Or, alternatively, ALMs provide [...] iteration velocity [...] that Linux developers don't care about.

I agree and that's why the author quoting Greg Kroah-Hartman about commit velocity (throughput of "8 changes per hour") in his article is actually a distraction from answering the actual question as stated in the article's title. The real reason for kernel devs use of emails isn't the throughput.

Re: Why kernel development still uses email (2016)

#56

Post by erikbye »

bassman9000 wrote: post #51
jasode wrote: 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…

4000 developers sponsored by 400 companies. Let than sink in. It's not only 4000 opinionated devs. It's, potentially, 400 completely different organizations; 400 management layers on top; 400 different priority sets; devs in every time zone; etc. Google is just 1 company (a dozen, if you want to break down Alphabet). It's amazing that they manage to get 8 changes an hour, and still be one of the most successful open…

14000 developers from 1300 companies have contributed, since 2005.

From 3.19 to 4.7, an average of 4600 lines of code was added daily.

Over 80% of all kernel development is done by developers paid for their work.

A small number of companies are responsible for a large portion of the total changes. These being, from biggest to lowest contributor: Intel (12.9%), Red Hat (8,0%), Linaro (4%), Samsung, SUSE, IBM, Google (2%), AMD, Texas Instruments, ARM, Oracle.

Contributions from unpaid developers have been in decline for many years. 14.6% in 2012, 7.7% in 2016.

Re: Why kernel development still uses email (2016)

#57

Post by makapuf »

abiox wrote: post #49
jasode wrote: post #46

Earlier quoted context omitted.

>using (or not) an alm in an organization isn't about "throughput", it's about "accepting" a company's policy assertions. I don't think that equating it from the reverse direction works. Here's why: Using the article's count of ~4000 developers, let's consider all software companies that employ 4000+ developers as part of a "natural experiment"[1]. This includes companies and organizations like MS, Facebook, NASA, SA…

> Since companies have every incentive to develop software with cost-efficiency and velocity, they will want to use the best workflow possible. in the abstract these are generally viewed as or presumed to be positive, but the pressures and objectives of a business can be rather complex and other things will often compete for finite resources. having worked in a number of large organizations, the waste and inefficienc…

having worked in large and small orgs, what I can say is, sure, a large org has many more inefficient workflows and latency than a smaller one. However it also has much more drive than the N independent smaller orgs it needs to accomplish the same scope. As a whole, a bunch of 10 person startups is generally more inefficient to accomplish something a big enterprise can do. (and of course, to accomplish what a startup can do, a big org won't be able to do for ages. Formula one vs huge train.) My point being, dont compare a big organization with a small team. Compare a small team within this org with an independant team. The indeêndent team wins, but not by far. With several competing small startup, the thing is, you cannot see the inefficiencies.

Re: Why kernel development still uses email (2016)

#58

Post by pmoriarty »

nextos wrote: post #53
pmoriarty wrote: post #35

Earlier quoted context omitted.

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

I ran Gnus with notmuch backend (nnir-notmuch) for many months. It's not very fast as Gnus is not very quick on Maildirs. Scoring could be quite easy to implement with auto-tagging. Tags are a unifying concept in email. You can implement any custom user logic with tags. What notmuch is missing is a bit of tooling to do this. It'd be cool if this tooling had access to any arbitrary header, as you have pointed out. I f…

Autocompletion from the notmuch database is fine when you don't have many addresses in there. But when you are subscribed to a bunch of large mailing lists and you try to search your notmuch database for "John" you're going to get a thousand completion candidates.

If instead you search just your BBDB database, which only has the contacts you actually correspond with, you're going to get just the useful and relevant ones... and you'll always have the notmuch database to search on as a backup, in case the contact you want to to correspond with is not in BBDB yet.

Re: Why kernel development still uses email (2016)

#59

Post by ivan_gammel »

blauditore wrote: post #5

(Unrelated to the e-mail topic) > A poor craftsman famously complains about his tools, Greg said, but a good craftsman knows how to choose excellent tools. Unless their company forces tools on them. :(

Actually good craftsman knows how to use the tools available to him to do the job in the most effective way. Choice is a luxury that is not always present.

Re: Why kernel development still uses email (2016)

#60

Post by erikbye »

na85 wrote: 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.

Email is the pinnacle of human communication.

Without notifications, which I, of course, do not use, email is the least intrusive and least disrupting way someone can contact me. I simply check my email when I feel like it, which is about two times daily, morning and sometime late evening.

Then, even when I look at my email, I don't have to respond. I don't have to do anything. And if there's an email I want to reply to, I won't necessarily do so right now. Maybe tomorrow. Maybe never.

The best part is the record of all communications and the fact that you have a searchable archive. Man, I wish I could search all my other conversations with people. In fact, I think I should just start recording everything, every day, all the time, and convert the audio to text.

Post reply on HN