Why kernel development still uses email • Hacker News Board

Re: Why kernel development still uses email

#71

Post by exDM69 » Sun, Oct 02, 2016, 10:06 AM UTC

erikb wrote: post #69

exDM69 wrote: post #66

tl;dr: my wish is a code review convention for git-notes and a friendly UI on top. If only Git would allow storing reviews and issues in the repo proper. Something like Git notes with conventions to refer to files/lines in a file/different revisions etc. Something similar to Fossil. This would solve half of the problem. The other half would be the UI layer. Now the reviews live in a database, outside of the repo, and…

Why does email not solve your problem? It allows offline work, you can store the reviews on your computer, you can even commit it to git if you want. Also check out emacs' org-mode for an alternative approach. And last but not least, does it just sound like you value the review higher than the code? Why should it be more than a text file like any other? Meaning is something we add to the text. A tool with a specific…

The review comments still live outside of the repo, in an unformatted ad-hoc format that's not easy to write a nice UI for. Ideally, I should be able to add review comments in a graphical diff viewer or web front-end and every dev should be able to choose the tools they prefer.

Email workflow would solve the connectivity issues, but the reviews, issues etc are not stored for posterity along with the code.

Reviews don't need to be much more than text, but they need some metadata to refer to files/revisions/lines. Basically this could be solved with some conventions on top of text files that machines could understand.

What I'm after is something like Fossil, where all the project management can be done offline and in a structured way.

Re: Why kernel development still uses email

#72

Post by douche » Sun, Oct 02, 2016, 10:07 AM UTC

cel1ne wrote: post #51

nxc18 wrote: post #17

Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard with many implementations on both the client and server. It is exceptionally easy to manage email. Many servers have great systems for categorizing emails and storing them long-term. Email is fast. Everyone has one. There is this weird myth that Email magically kills productivity while Slack and GitHub don't. I never underst…

> There is this weird myth that Email magically kills productivity while Slack and GitHub don't. Yes. I really can't abide chat for work. If I have time and need synchronous communication, I make a phone call. Email forces me to think my communication through, and I can explicitly CC/BCC other people if I feel that they need to read my letter. PS: I find it telling that the product is actually called "Slack". ;)

I can't abide ad-hoc phone calls, unless somebody is bleeding out or the server rack is bursting into flames.

If I'm trying to work on something, hitting me in the back of the head with a claw-hammer would be scarcely more disruptive than an unsolicited phone call.

Re: Why kernel development still uses email

#73

Post by erikb » Sun, Oct 02, 2016, 10:08 AM UTC

blaisio wrote: post #8

So I get and agree with what he's saying about how GitHub duplicated email, but as a millennial who uses Vim, I find GitHub much more intuitive and useful than sending patches via email. In general, I disagree with the issues he has with GitHub - most of them are wishy washy disagreements that could easily be solved by adding things to GitHub or using a chrome extension. IMO the only real, logical reason they need to…

Sorry, but "adding things" won't solve all problems. Often adding more is what makes more problems, and removing something is what makes things work. And sometimes it's removing the html, css and js around your text.

Re: Why kernel development still uses email

#74

Post by astrobe_ » Sun, Oct 02, 2016, 10:11 AM UTC

makomk wrote: post #60

dredmorbius wrote: post #24

Earlier quoted context omitted.

Email is tremendously useful, and whatever replaces it should borrow from those useful bits. It also has numerous problems. Some are listed in the article: 1. Clients (and some servers) mangle email. You can't be assured that what you send is what someone else will receive. I blame the clients and servers here, but ... 2. Privacy. This has become among the biggest downsides. Whether it's data-in-flight or data-at-res…

Number one on your list is a big issue with using e-mail for kernel development. If you want to submit patches by e-mail, you have to install and configure one of a handful of clients that doesn't mangle the patches first. There's a list in the kernel documentation and they're not terribly user friendly. (In fact, by necessity they have to be, because not wrapping lines automatically is terribly user-unfriendly and r…

People who are into kernel development are unlikely to be defenceless against garbage email clients. They're actually the type of people who can write a script in an afternoon to solve the issue.

Re: Why kernel development still uses email

#75

Post by austincheney » Sun, Oct 02, 2016, 10:14 AM UTC

nxc18 wrote: post #17

Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard with many implementations on both the client and server. It is exceptionally easy to manage email. Many servers have great systems for categorizing emails and storing them long-term. Email is fast. Everyone has one. There is this weird myth that Email magically kills productivity while Slack and GitHub don't. I never underst…

> Email is an amazing tool. I don't understand the rush to get rid of it.

I would say that Email has its strengths, but there are still learned opportunities for improvement.

Email is a text based format. I mean this literally as in there is literally no convention to email aside from a couple specified fields in the message header, which often get auto-reproduced into the message body. We can do better on this front to increase accessibility, internationalization, and understandability.

There is greater AI potential from email than from the web. Email chains tend to represent conversations with the necessary networking information that both computers and humans similarly understand. This is absolutely missing from HTTP and requires a lot of custom assistance in the formatting of the output to make sense to either computers or humans on the web.

Email is less centrally managed than the web. The end points on email are message authors while the server is a glorified application router. On the web though the server is the end point, which is far more primitive.

Re: Why kernel development still uses email

#76

Post by austincheney » Sun, Oct 02, 2016, 10:18 AM UTC

gaius wrote: post #43

nxc18 wrote: post #17

Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard with many implementations on both the client and server. It is exceptionally easy to manage email. Many servers have great systems for categorizing emails and storing them long-term. Email is fast. Everyone has one. There is this weird myth that Email magically kills productivity while Slack and GitHub don't. I never underst…

Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard Answered your own question - no way to make money off it for "disruptors".

Perhaps the "disruption value" is not in media/advertising/content (as in the web) but instead in an enhancement that could erode certain attention from the web. Here is a potential example that will probably never see the light of day http://mailmarkup.org/

Re: Why kernel development still uses email

#77

Post by dredmorbius » Sun, Oct 02, 2016, 10:22 AM UTC

kijin wrote: post #38

dredmorbius wrote: post #24

Earlier quoted context omitted.

Email is tremendously useful, and whatever replaces it should borrow from those useful bits. It also has numerous problems. Some are listed in the article: 1. Clients (and some servers) mangle email. You can't be assured that what you send is what someone else will receive. I blame the clients and servers here, but ... 2. Privacy. This has become among the biggest downsides. Whether it's data-in-flight or data-at-res…

I think you're trying to have your cake and eat it too. Wouldn't a global directory of email addresses be the antithesis of privacy? The greatest difference between email and all of today's proprietary alternatives is that your email identity doesn't need to be vetted by any central authority. Of course this makes spam harder to deal with, but it's part of the cost of decentralization and one that we must learn to de…

My inclusion of directory as a downside of email was a poor choice on my part -- I occasionally get swept up in writing something, and the thought's been kicking around my head for a few days that email is NOT based on a global directory, but a directory of directories, possibly hierarchical. This means that if you want to get something somewhere, as with routing and DNS, you kick it off first in the right general direction -- someone who knows more about such things than you do, at a minimum.

So, you're right, the fact that email doesn't have a global directory is a feature. It's a feature that's underappreciated by a great many folks who've suggested alternatives to email that do rely on grand central unified directories.

Which suggests that an email alternative which has a similar directory-of-directories concept might stand a better chance.

I've been thinking along lines of clustered hierarchies of users, with various trust bases within them. If you wanted clusters of no more than about 50 neighbors (well within a Dunbar exhange), then a hierarchy 6 layers deep gets you to coverage of all of Earth's population (15.6 billion individual nodes). Deeper, cross-linked, or other structures could offer greater depth of address use for individuals.

I've also been wondering if perhaps national postal systems ought to take over electronic messaging. I can hear the screaming already, but with privacy-supporting protocols (including metadata), much of the risk might be mitigated. In particular, I'm interested in addressing the "who are you?" question -- identity, and re-establishing it, is difficult.

I'm thinking that a good reputation system, and perhaps a poll-and-fetch method, rather than a straight delivery, could make email much more resistant to spam.

Under poll-and-fetch, a sender would indicate that it has a message for another party. That party would then fetch the message, should it be interested. Fully vetted senders would have their content fetched automatically. Spam senders would have to sit on their spools and wait for (and support) many individual incoming fetch requests. Spammers identified as such would be identified through reputation systems.

Granularity of reputation might be at IP space, domain, mail host/peer, or individual sender basis.

For many sender/recipient pairs, a strong and clearly positive or negative relation would be established early. The hump is to become known as a trusted sender, for which some sort of trust seed or reputation vouching system might work. I'm still hazy on what might work there.

Re: Why kernel development still uses email

#78

Post by dredmorbius » Sun, Oct 02, 2016, 10:22 AM UTC

digi_owl wrote: post #25

dredmorbius wrote: post #24

Earlier quoted context omitted.

Email is tremendously useful, and whatever replaces it should borrow from those useful bits. It also has numerous problems. Some are listed in the article: 1. Clients (and some servers) mangle email. You can't be assured that what you send is what someone else will receive. I blame the clients and servers here, but ... 2. Privacy. This has become among the biggest downsides. Whether it's data-in-flight or data-at-res…

I do wonder if we could get XMPP to adopt store-and-forward messaging...

How do you mean on that?

Re: Why kernel development still uses email

#79

Post by dredmorbius » Sun, Oct 02, 2016, 10:26 AM UTC

makomk wrote: post #60

dredmorbius wrote: post #24

Earlier quoted context omitted.

Email is tremendously useful, and whatever replaces it should borrow from those useful bits. It also has numerous problems. Some are listed in the article: 1. Clients (and some servers) mangle email. You can't be assured that what you send is what someone else will receive. I blame the clients and servers here, but ... 2. Privacy. This has become among the biggest downsides. Whether it's data-in-flight or data-at-res…

Number one on your list is a big issue with using e-mail for kernel development. If you want to submit patches by e-mail, you have to install and configure one of a handful of clients that doesn't mangle the patches first. There's a list in the kernel documentation and they're not terribly user friendly. (In fact, by necessity they have to be, because not wrapping lines automatically is terribly user-unfriendly and r…

If you're sending email, it's trivial to use, if all else fails, a shell tool or application-based email client. Standard unix mail, mailx, mutt, or various mail utilities within Perl, Python, Ruby, etc., can all be adapted to accept patches and some cover text with ease, largely noninteractively.

If you're actually reading email off LKML, that's another story.

But seriously: mutt, pine, Emacs mail mode, or even graphical clients such as Evolution or Kmail, will work just fine. And can be used in conjunction with nontechnical (there's another phrase I'm avoiding using here) GUI mainstream email clients used for other tasks.

If you can't figure out how to install and use mail / mailx / mutt with git, you probably shouldn't be submitting kernel patches. Which in this case is a useful filter.

Re: Why kernel development still uses email

#80

Post by jjawssd » Sun, Oct 02, 2016, 10:33 AM UTC

deckard1 wrote: post #26

nxc18 wrote: post #17

Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard with many implementations on both the client and server. It is exceptionally easy to manage email. Many servers have great systems for categorizing emails and storing them long-term. Email is fast. Everyone has one. There is this weird myth that Email magically kills productivity while Slack and GitHub don't. I never underst…

> I'll need to find and install one of the x tens of IM clients. Only one? :) It got so bad at my company, that at one time we were having conversations on 3 platforms. And, of course, no one emails anything! Because it's all done on Slack or whatever now. So everyone is 100% out of the loop at all times. I'm up to about 20 Slack channels. I'm constant switching between things to see if I need the information. We hav…

Some parts of the US military have standardized on http://psi-im.org/

There are private networks with hundreds of active users.