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

41–50 of 97 posts

Re: Why kernel development still uses email (2016)

#41

Post by jasode »

wmf wrote: post #39
jasode wrote: post #30

Earlier quoted context omitted.

>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?

>; what about developers who refuse to use the email-based process?

I guess I don't understand your question. In Linux, the email-as-the-workflow[1] has been agreed upon from Linux Torvald and his lieutenants all the way down.

I suppose that if a one refused to use email-based-workflow, they'd have to find a Linux kernel maintainer to be a champion for their proposed changes and submit them on their behalf. (Is this a common scenario? I don't know.)

If a rebel Linux kernel programmer insisted on staging changes for review in Gerritt/JIRA/github/etc, he's going to be isolated in an island because he's not part of the agreed-upon workflow: emails.

[1] https://github.com/torvalds/linux/blob/master/Documentation/...

Re: Why kernel development still uses email (2016)

#42

Post by abiox »

na85 wrote: post #28
AndyMcConachie wrote: post #27

Earlier quoted context omitted.

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.

btw "echo chamber" is generally perceived as disparaging, so it's not weird people wouldn't be impressed by that. and feigning victimhood after antagonizing people is pretty gauche.

Re: Why kernel development still uses email (2016)

#43

Post by abiox »

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

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.

trashing a community doesn't often get upvotes. perhaps if you were really funny or clever about it.

Re: Why kernel development still uses email (2016)

#44

Post by ori_b »

leeoniya wrote: post #16
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…

> my conclusion is, email threading is mostly a pipe dream

Them why has it been working so well for me since I started using email?

Maybe take a look at this for inspiration: https://fkref.com/?RbC_-NEE

Re: Why kernel development still uses email (2016)

#45

Post by wmf »

jasode wrote: post #41
wmf wrote: post #39

Earlier quoted context omitted.

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

>; what about developers who refuse to use the email-based process? I guess I don't understand your question. In Linux, the email-as-the-workflow[1] has been agreed upon from Linux Torvald and his lieutenants all the way down. I suppose that if a one refused to use email-based-workflow, they'd have to find a Linux kernel maintainer to be a champion for their proposed changes and submit them on their behalf. (Is this…

If Linus declared that everyone must use, say, Gitlab from now on, some Linux developers might leave. But developers who don't use email may never start working on Linux. That's why it cuts both ways: either option alienates some developers.

Re: Why kernel development still uses email (2016)

#46

Post by jasode »

abiox wrote: post #40
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…

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

>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, SAP, Oracle, etc.

Each company "votes" in the marketplace of ideas to coordinate software development for a complex project. One company might use JIRA. Another uses MS Team Foundation. Another uses FogCreek. Maybe another employer might use SMTP emails similar to Linux kernel development.

Since companies have every incentive to develop software with cost-efficiency and velocity, they will want to use the best workflow possible.

Since no single software company I know of uses SMTP emails as their ALM workflow, it either means that (1) companies are wasting money & losing iteration velocity by avoiding email -- or -- (2) the Linux kernel community has special circumstances that makes using a true unified ALM unrealistic. I believe that special circumstance is: 4000 programmers work for different employers instead of a single employer.

[1] https://en.wikipedia.org/wiki/Natural_experiment

Re: Why kernel development still uses email (2016)

#47

Post by kcorbitt »

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.

Eh. If you were to measure the percentage of personal communication that users of this forum conduct over email as opposed to other mediums (Whatsapp, FB Messenger, iMessage, etc.), I bet you'd find it indexes way higher than the general population.

Re: Why kernel development still uses email (2016)

#48

Post by leeoniya »

ori_b wrote: post #44
leeoniya wrote: post #16

Earlier quoted context omitted.

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…

> my conclusion is, email threading is mostly a pipe dream Them why has it been working so well for me since I started using email? Maybe take a look at this for inspiration:  https://fkref.com/?RbC_-NEE

thats basically what i did.

the problem is with this step:

4. Prune empty containers.

you can prune/flatten these containers but then the deeper messages that you do have are not direct replies to their ancestors in the flattened/pruned version of the tree.

i didnt say that threading did not work. it does. but it is imperfect at best and can be misleading at worst.

in my case i was constructing an MPTT structure (Nested Set) for optimal thread fetching and simply leaving in the dummy message placeholders that i didnt have a copy of.

i plan to experiment further, but there arent really any earth-shaking revelations in that post. it's all fairly obvious.

Re: Why kernel development still uses email (2016)

#49

Post by abiox »

jasode wrote: post #46
abiox wrote: post #40

Earlier quoted context omitted.

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

>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 inefficiencies one can find is absolutely staggering.

outside the sales pitches, it's also not clear how an alm interacts with notions of 'cost-efficienty' and 'velocity'. introducing process and bureaucracy isn't always a win.

perhaps the presumed predilection of large organizations for alms can be found in alms addressing (or seeming to address) other needs, pressures or requirements.

Re: Why kernel development still uses email (2016)

#50

Post by marcosdumay »

jasode wrote: post #46
abiox wrote: post #40

Earlier quoted context omitted.

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

>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.
Post reply on HN