Live data from Hacker News

Why kernel development still uses email (2016)

lwn.net

91–97 of 97 posts

Re: Why kernel development still uses email (2016)

#91
I think a crucial point is missed: email does not have a single point of failure.

If you go through a website, a server downtime halts the development. If the mailing list crashes, patches can still be sent and some discussions kind of continue until it is resolved.

Individual email servers may fail, but it is easy to work around it. Many people have several email and other channels through which to be reached.

Also, a very important point that Linus explained was at the core of some design decisions for git: it works offline. You have your email archive offline so if you take a plan, are at a conference in a place with no internet (does still exist, sadly), are on the road, you can still go through your archives and the patches you have to examine are still available.

Re: Why kernel development still uses email (2016)

#92
post #75
post #72

Earlier quoted context omitted.

Perhaps. I prefer to see it as the down votes reaffirming that I am correct.

you are correct. if people get triggered by someone using the word "echo chamber" they are probably in one. It's hard to admit, I know.

what do you mean by "get triggered"? if someone downvotes trashtalk, does it necessarily mean they "got triggered"? are there other explanations?

Re: Why kernel development still uses email (2016)

#93
post #92
post #75

Earlier quoted context omitted.

you are correct. if people get triggered by someone using the word "echo chamber" they are probably in one. It's hard to admit, I know.

what do you mean by "get triggered"? if someone downvotes trashtalk, does it necessarily mean they "got triggered"? are there other explanations?

Yes. Because it wasn't trashtalk. HN in generel seems (from what I observe) like a place that uses fancy apps for communication instead of emails. So if someone claims that HN doesn't like emails and get downvoted for that, they got triggered.

Re: Why kernel development still uses email (2016)

#94

Earlier quoted context omitted.

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.

Just because you say that doesn't make it true, though. Sometimes a tool just is worse, even if you become skilled at it. I can try to work around Microsoft Word's UI by learning the keyboard shortcuts, but I can't do anything against Internet Explorer taking its sweet time loading webpages. No skill in the world will make that faster.

Well, that's the point. If you can get your job done with IE (I can only guess what kind of job is that), you just do it without pointless clicking, pressing F1 button or anything else that does not belong to the path of success. Talks about "it's worse", "omg it's so slow", "why not firefox/chrome/whatever" are meaningless when you are in strict corporate environment with only IE allowed or even possible. True professionals do not pay much attention to the tools. They pick the best when they have choice or find the way to use what's available, because craftsmanship is not about the tools.

Re: Why kernel development still uses email (2016)

#95
post #18

Earlier quoted context omitted.

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

This makes no sense.

1. You shouldn't expect that it would "always hold true". I really don't know why you would, because I did not write that it would always hold true. In fact, what I did write is the opposite: a tacit acknowledgement that it's not a hard and fast guarantee. I mean, I specifically made comments like, "Like so many other things, this only works if you enforce it". It's right there. You can go back and read it. Thing is, I even edited my comment (before you read it and responded) from the original; I edited in the words "can help" so that it says "the unthreaded approach can help keep the discussion focused". You want to know something perverse? While doing this, I stopped and asked myself whether I was hedging too much—writing too defensively. Apparently the answer to that is a big nope; I was still not defensive enough.

2. Regardless of everything above, the page you linked to is supposed to prove what? It's a misdirected pull request, and the very first comment is a message to the requestor telling them so. I don't know what you expect past that; even after the message explaining that GitHub is not the correct place to make a pull request and that it will not be moving forward, you seem to be trying to score the discussion against a rubric of how effective the discussion was at staying focused. Do you not see what's wrong with that?

3. I made an a priori remark about how lousy the GitHub community is in my very first comment. I mean, my exact words were calling out what's found on GitHub as "pretty horrifying". If there's some way to be clearer regarding how I feel about GitHub, I don't know what it is. GitHub is terrible. And yet, despite this, despite everything above, your choice example is to link to a GitHub thread where this exact thing is on display, in an attempt to prove me wrong. Or something. I don't get it.

This'll be my last comment here. I think I'm gonna go away for a while.

Re: Why kernel development still uses email (2016)

#96
post #18

Earlier quoted context omitted.

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

This makes no sense. 1. You shouldn't expect that it would "always hold true". I really don't know why you would, because I did not write that it would always hold true. In fact, what I did write is the opposite: a tacit acknowledgement that it's not a hard and fast guarantee. I mean, I specifically made comments like, " Like so many other things, this only works if you enforce it ". It's right there. You can go back…

My reply wasn't meant to be disparaging in any way. It was to point out that your assertion that unthreaded discussions tend to be more focused and tight compared to threaded discussions isn't necessarily true.

Regarding the example I cited. it's an unthreaded discussion that has been going on for several years and, if you bother to read through it, it's a mixture of troll comments along with some informative comments/discussion. Had it been a properly threaded discussion, it would have been much easier to follow the informative thread branches and filter out the uninformative ones (where the classification of what falls under one category or the other is up to the person reading it).

But, because it's not threaded, you're effectively forced to wade through all the troll posts to find the informative comments (or miss the informative comments entirely if you're not willing to do that). The lack of threading did not change the "social aspect" of the discussion. It would have been the same either way given the topic, but one way of rendering it would have made it much easier to follow (and possibly spawned more informative discusson about the topic compared to what actually took place).

Getting back to your points:

> the very first comment is a message to the requestor telling them so. [...] after the message explaining that GitHub is not the correct place to make a pull request and that it will not be moving forward

If your assertion about unthreaded discussions was true, then it should have ended soon after that comment (maybe after a couple of comments from the person who submitted the pull request after Linus' comment). That obviously wasn't the case and nothing kept it in check.

> the unthreaded approach can help keep the discussion focused

Based on what I've read online over the years (both threaded and non-threaded discussions), it doesn't seem to be the case. The only way I think this could be settled would be to come up with a representative sample of discussions under both formats and how well they stay on the original topic compared to each other. It would be interesting to see the results of such an analysis.

Re: Why kernel development still uses email (2016)

#97
post #96

Earlier quoted context omitted.

This makes no sense. 1. You shouldn't expect that it would "always hold true". I really don't know why you would, because I did not write that it would always hold true. In fact, what I did write is the opposite: a tacit acknowledgement that it's not a hard and fast guarantee. I mean, I specifically made comments like, " Like so many other things, this only works if you enforce it ". It's right there. You can go back…

My reply wasn't meant to be disparaging in any way. It was to point out that your assertion that unthreaded discussions tend to be more focused and tight compared to threaded discussions isn't necessarily true. Regarding the example I cited. it's an unthreaded discussion that has been going on for several years and, if you bother to read through it, it's a mixture of troll comments along with some informative comment…

[deleted]
Post reply on HN