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 understood this - slack and GitHub have a lot more distraction with their social media components.
I see the day coming soon when in order to work with other people I'll need to find and install one of the x tens of IM clients. The day when I can't find anything because it is in a million places and its real hard to search 10 years of conversation when messages don't have basic metadata like a subject. :(
> 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 have Github integration (and 10 other things) into everything, so it's a constant stream of garbage. And stupid gif animation integration. God forbid you take time off work. Good luck catching up on all that mess.
People like to shit on IRC today. But at least I got to choose the client I wanted, and log to an actual file that I could actually grep on. And timestamp on. And organize. And block all the stupid nonsense. First thing on the cutting block would be ignore all Github.
GitHub is really useful for issue tracking on open source projects. It's annoying to have to hunt through whatever 90's era mailing list archive website to see if someone else has had the same issue on projects that don't use it.
It would be nice if discussions were done on a newsgroup instead. At least you don't have to be part of the conversation and you can read through discussions as far back as the retention policy on the NNTP server allows.
Man, your Github notifications are mixed into Chat?
We have a #{{projcet}}-dev channel for talk and #{{project}}-admin for JIRA/Github/etc. Also, in Slack you can have it auto-close all expansions. You choose the Gifs you wanna see.
Unfortunately, slack doesn't allow you to block users - not even bots or webhooks. And even if you have expansions turned off, they're still there in collapsed form.
So if you're not an administrator, and some genius has set up a bot that posts a cute puppy every time a message includes /pup, and it triggers practically every line in a discussion about puppet, slack doesn't give you the option to do anything.
Well, apart from "complain to your boss and ask him to stop your co-workers' fun". As a professional, I don't want to be wasting my boss's time with trivial shit I ought to be able to fix myself.
I do. Do you want to really be "that guy" who hates puppies (and is ribbed about it all the time)? Software development teams often have all the maturity of a clique of middle schoolers; and exclusion can be just as harsh.
I'd say that people that don't have the maturity to raise a legimitimate work issue with their coworkers are more likely the immature ones.
I have been and continue to be "that guy" who says "this is interfering with work, let's fix it", instead of that guy who doesn't say anything and instead just complains anonymously on social media. It works better this way.
Yeah Slack makes it really easy for things to get out of hand. One of my informal roles at our company is being the Grim Reaper of Slack. I periodically go through and delete slackbot responses and emojis that have proven to be very annoying. People get salty at first, but if you don't stay on top of it, your shop will eventually be overrun by parrots.
I really like Slack, I think it is the team/company responsability to maintain a controlled focus. The same issue can apply with email.
When a customer adds one member of my team to Slack and the flow of information is insane I charge the customer for a manager to follow the loop and leave developers focused.
Fortunately, Slack does provide an XMPP and IRC gateways. Assuming they're enabled, using them is a much better experience (no animated gifs and all the power your chosen irc/xmpp client can provide you).
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/
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.
I can't abide ad-hoc synchronous communication, not just phone calls. It's the reason I'm almost constantly wearing headphones, whether I'm listening to something or not.
I sometimes hear that a cow-orker is talking to me, but I ignore it on purpose, pretending not to notice. Then they usually figure out they need to attract my attention somehow, so they come over / wave their hands / throw an object at me. I respond politely, but with very visible annoyance. This quickly trains them to use IM instead. IM, for which I often have notifications turned off.
Avoiding distractions at workplace is a hard work in itself.
Best workplace for creative work like programming is a room for yourself.
The shared office concept was a mistake inspired by assembly lines. Sharing space with coworkers is good in factories because work is often dull and workers can talk to each other.
For creative work, it's nothing but a hindrance.
I work in a team and find it very useful to easily speak with a coworker when necessary. The increased degree of communication has a very positive impact for me. And I don't feel the need to shit on factory work, which I have never done and suspect you never have, when discussing it.
I feel that this is more an issue about bad managment. When your managers are bad to create good communication between teams, sharing the same workspace is a pretty neat workaround that can save a project.
> 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.
It's apples and oranges. Email, phone, IRC/Slack/Lync/Hipchat/Discord. They all have their own purposes. I don't think many companies are trying to replace email; just provide an alternative for times when email would be unnecessary and bulky.
I like to think of email as the "ledger" or repository, while your IRC alternative is your working branch.
Email requires all participants to play nice and write their emails with subjects and quotes in a manner that other people and their mail clients can work with, read and understand.
However, many clients have different defaults and many people have different preferences.
Do I quote above or below? Does the subject line start with RE:, RE:RE:RE:? Maybe my client is setup in a different locale and the reply is prepended with SV: or what have you. Maybe a participant hates RE: and removes them from the subject line, or write the subject line as the main point of the reply.
I've never been able to setup a client to show me what is going on on a mailing list or show me nice tree structures that could help me follow the different branching a discussion goes off in. I often get mails in the middle of a discussion and can't trace it back, and read the thread from the beginning. And it is every client for himself and I'm the idiot for not having everything setup nicely and everybody else is smug about it.
The nice thing about closed standards is that all clients follow the same rules. When you click reply, you are replying to that message, no matter what you write in your subject line.
Email is tremendously complex, uses multiple protocols to accomplish different tasks (or even the same task), and is fundamentally vulnerable to spam and can only be patched with further complex hacks like SPF. Almost everyone now uses HTML email, an ill-defined and insecure idea, adding to the complexity of implementations.
If you think that email is a good system, trying setting up postfix, dovecot, sendmail, and whatever other hacks are required to make email usable.
The complexity of email isn't a problem for the average end user who uses someone else's mail server (like me). It's a problem because anyone who wants to interface with email directly takes on the burden of the complexity, meaning fewer and lower-quality implementations of the protocol(s) and less innovation overall.
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-rest, email remains an exceptionally poor choice for private communications, and there's been little real progress on addressing this, in large part because of vendor reluctance at both client and server / system level. E.g., Microsoft, Google, Yahoo, and AOL.
3. Users. Systems which work well with email rely strongly on compliance by users, which relies strongly on enforcement by communications managers or moderators. For LKML, that would be the kernel mailing list etiquette. Battles over header formats, quoting styles, and quote before vs. after exist because these strongly impact workflow and efficiency of groups as a whole. Failure to acculturise hampers the group, and acculturisation rates limit group size and growth.
Much of Linus's noted "personality problems" come from the task of having to corral a group of people over which he has little if any formal control, a decidedly limited-bandwidth social communications channel (e.g., no tone, expression, voice, facial gestures, etc. signals), and the necessity TO BE UNAMBIGUOUSLY CLEAR when someone is transgressing norms. (Yes, I'm aware of HN's norms on ALL CAPS.)
4. File formats. Both a blessing and a curse: you can send anything. This means any given group can specify its preferences, but also raises the problem that there are few global preferences given. Kernel development works well with email by having specific tools and formats, from coding style to patch and git tools which create workable code fragments, to conventions for list discussion. This is strongly linked to #3 above.
5. The directory. In thinking about how email compares with other proposed alternatives, one key is that email lacks the concept of a central directory. Or at least, not a formal one (spammers may trade in same). On Twitter, or Facebook, or HN, every individual user is uniquely identified within a global directory. In Email, by contrast, what exist are addresses, which is to say, <user>@<domain>, where the domain has its own sub-directory. But there's no guarantee that domain1 would know that user1 is some valid directory entry at domain2. At best, domain1 knows how to reach domain2, and attempt delivery, via DNS, generally though not necessarily through MX records. This becomes more of a problem with ...
6. Spam and spoofing. Because there's no global directory, the validity of an email from <user2>@<domain2> cannot be assessed. In fact, there's no requirement that that even be a valid address, though as a convention it's generally considerate and useful. There've been numerous hacks to add increasing levels of authentication to email (SPF, DKIM), but the protocols remain weak. There's a much broader problem of metadata leakage. Deriving from this:
7. Reputation. Much of the spam problem derives from poor tools and support for establishing, assessing, sharing, and acting on the reputation of specific senders -- whether individual originators, email hosts, domains, or IP ranges. Changes to how the Internet is being used, including very large aggregated email providers (e.g., Google, Microsoft, Yahoo, AOL), and point-of-origin masking systems such as Tor make formerly useful concepts of IP and domain-based reptuations of limited reliability. And a consequence is that the assurance of getting messages through to any one person are becoming quite low. The more users are added to a system, the higher the noise level.
Email was designed for a friendly, unencrypted, lightly used system of mostly known and fairly trusted users numbering in the thousands. It's scaled remarkably well, by roughly six orders of magnitude. But it's become exceptionally creaky.
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 deal with. Fortunately, most of the email services I use are pretty good at filtering spam, as well as making sure that my emails don't get marked as spam by other email services.
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.
Your poll-and-fetch suggestion sounds really interesting. Even if is not combined with a widely used reputation system, it would greatly increase the cost for spammers by requiring them to stay online indefinitely. It's basically graylisting on steroids, but without the annoying delay that graylisting imposes on every sender.
Mind that that cost can be met by some spammers, as it's effectively how a number of present online systems work. But in general, spammers tend to be taken down, and you remove the fire, cram, and forget mechanism of mail blasters, or the sparse, wide botnet model, where a given node emits only a relatively small number of messages.
Adding reputation to the mix strikes me as the secret sauce though.
Thanks for that. Yes, djb has thought through a lot of matters of trust and ought be considered. I'll take a look at that, I think I've read it before.
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 required by kernel development. So the only clients that meet the criteria are the ones that don't care about being a pain in the ass to use, and this permeates the entire user experience.) This isn't an issue for the core kernel developers because they already have a suitable e-mail client configured and installed which they're used to using, and because they're generally not submitting patches that way anyway.
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.
Wait, I thought patches are typically attached, not sent in-line on lkml? Admittedly I've only ever submitted a patch once, in 2002 or something - and at the time I was using pine as an email client.
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.
> you have to install and configure one of a handful of clients that doesn't mangle the patches first.
git-am and git-send-email are used by some people. Submitting patches using those tools is just a matter of setting up the necessary parameters (email server and authentication information). But you can use any email client to participate in discussions about a patch series regardless of whether or not it mangles text (since review comments or further discussion obviously do not need to be applied to one's local copy of the code).
Regarding 5. what's wrong with opt-in and mandatory email lists?
If you want to reach a team, email team@example.com. When you join a team, email team-subscribe@example.org, or maybe your hr/sysadm will add you to team@example.com. If you want to reach person@example.com - if you're part of the same company, your client does an ldap lookup. Or you have a look at https://example.com/employees.html or contact.html.
It might at times be difficult to find a random person's email - if you know nothing other than the name - but it's generally very easy to find a contact email for a Dev/security team for a project or company?
I think the matter of lists is orthogonal to the issue of global directories.
I have ... well, not quite nothing, but little against the concept of email lists. They're useful. I've used them extensively. They don't, of and by themselves, address numerous other problems with email. And they can and do insert a few of their own.
Regards lists and directories, I'm not entirely sure what your argument is, but I can interpret your comment at least two ways:
First, an email list is a directory. Yes, it is. It is not, however, a global one. In the right contexts, a list can address the question of discoverability, but that's somewhat secondary. There's the question of what mail is or isn't allowed on-list (e.g., is it open to all senders, or subscribers only?). Service lists -- the effective utilisation of addresses such as postmaster@ or webmaster@ -- typically have to be fairly widely open. This creates some well-known issues, mostly having to do with spam, but also of privacy and organisational confusion over who should or shouldn't be receiving such messages, or how they ought respond. For many corporate distributions, the names of such lists are not generally advertised outside an organisation, though likely targets include "all@", "sales@", "engineering@", etc. Again, this can be useful or not.
The other point you seem to be making is that an organisation can automatically manage its own lists through directory systems. Again, this is addressing the concept of a directory of directories, and any one of the (sub)directories might choose to expose or conceal elements to specific entities. Nothing in any of this is required or constrained by what I've written above.
More generally, you seem to be addressing the question of discoverability, which is a general one. The idea that organisations with their own individual entities might have or conceal means of reaching or contacting people is an old one. I'd call it the introductions problem.
An anecdote from personal experience. At various times, I've had an interest in contacting specific people at organisations. Two come to mind -- an IBM director over a matter somewhat concerning the company, and an issue involving spam transiting a Microsoft-run service. My general biases are that I'm favourably inclined toward IBM, and unfavourably toward Microsoft.
In each case, I found a general switchboard phone number and called, asking for the individual by name.
In the case of Microsoft, the operator said "just a moment", connected me through, the director picked up on the first ring, we had a brief conversation where I described the problem (about five minutes or less), he said he'd get me in touch with the person I needed to talk to, took my number, and within fifteen minutes I was talking to the manager in charge of the unit. We worked on the issue (I had better information than him) for a few months whilst they resolved it, quite measurably.
In the case of IBM, I was connected to an administrative assistant who said, and I think I'm quoting directly, "You can't talk to him, he's a director".
I'm struck by the difference to this day. Much as I don't care for Microsoft, my impression is that they know how to run a business and to transmit information. On the other hand, IBM may have its reasons for sheltering its upper-level management. I suspect otherwise.
Interesting points. I guess I need some clarification as to what your perceived problem is - it sounds like email is equivalent to the phone system - are you saying you prefer facebook etc as a global directory, as opposed to specialized directories run by organizations?
The directory issue ties in with several of the other problems of email, and how you want to address them.
If we're assuming pervasive use of mobile devices, with no fixed static IP addresses, and quite possibly dynamic IPs even for stationary devices, several of the avenues to establishing reputation, identity, and routing get difficult.
If the idea is to offer a very large number, rather than a small number, of messaging hubs (equivalent to, though offering more services than, an email server), then issues of reputation, configuration, and administration come into play. You want something that's simple, bulletproof (not in the spam-friendly sense), robust, and useful.
Many erstwhile email replacements are premised on a single global directory. I don't think this can work, nor is it on the whole desireable, though it's certainly simpler to get started.
For point-to-point messaging, especially if we're including realtime protocols (chat and voice/video, not just text/files), you need a system in which either scheduled contacts can be made, or in which at least certain trusted/whitelisted parties can reach a given device, regardless of location, within seconds, or at the outside, a few minutes, so long as both parties are online.
Avoiding central peering and routing structures should be part of the system, for privacy and resilience reasons.
Addressing a few of the other issues I mentioned above, including standards for comms and the like, should also be supportable.
Your list of complaints is approximately my list of laurels, but many of your complaints are not specific to email.
1. Clients (and some servers) mangle email. This isn't a complaint about email; it's a complaint about bad software in general. It's also not my problem; I don't use such clients or servers and it's up people who use them to work around these flaws.
2. Privacy. Real privacy is achievable via email with PGP; everything else is no different than literally any other form of communication. Privacy will always be between Alice and Bob. The transport layer is just a transport layer. With email, those who want it know where to get it. Sure, it's not simple, but if it were simple it would not work. With other solutions, it's frequently not even almost an option. I don't get to audit Whatsapp's server logs; who knows what agencies have access.
3. Users. All systems of communication rely on compliance by users. Just about none of your thoughts on this topic are specific to email. There is no 'go fmt' for human expression, and whenever someone tries, human expression is no longer present. Always speak to your audience, even in an email. It's up to you to decide if a given audience is important enough to acculturate to their norms.
4. File formats. You can send anything -- thank god.
5. The directory. This has no place in the layer. It's like complaining that they didn't build the concept of a web sitemap into TCP/IP. Twitter, Facebook, and HN are one-to-many communications platforms, some of which have hacky ex-post-facto one-to-one mechanisms. Email has been n-to-n from day one. Pretending that it is universally desirable to map addresses to individuals and vice versa is incredibly naive. I not only have several email addresses for different roles, but I have several phone numbers and several postal addresses for different roles. On twitter, facebook, and HN, I would have to jump through hoops to achieve this, and on some services it's even against the TOS. This lack of outside force regarding how I handle email messages is its greatest strength -- I can trivially set up a mailing list, which is nigh impossible on, for instance, twitter, and utterly impossible on hacker news.
6. Spam and spoofing. Absolutely a problem. Will remain a problem until solutions get specific buy-in from multiple interested parties -- and that last part makes all the difference. Each time some SV megacorp institutes a real-name policy, or a captcha, or or or... another class of users is sidelined, disenfranchised, or otherwise excluded from the communications process. Email does not have that, because there are standards to adhere to, and some random project manager does not (quite yet) have the power to shove new standards down our throats. Thank God.
7. Reputation. This is now and will continue to be the universal problem across all of the internet. Solving this problem by trusting a third party service provider to do all of your vetting for you will fail, because all they do is push that problem downhill to the users. Joe Random wants to be friends on Facebook. Now I have to do casework to decide if I want Joe to access my inbox, and if Joe is even Joe. Susan User would like to add me to her professional network on LinkedIn. Same problem. The only difference is that when I run an email server I maintain agency to manage the entire scope of these decisions, instead of trusting that Facebook or LinkedIn is reasonably sure that Joe might actually be Joe, or that Susan is not in fact a ten-year-old Martian girl mining my profile for password recovery answers.
Is email perfect? No, of course not. But it and IRC are the closest things we have to level playing fields for someone willing to do the work to take their place as a first-class citizen of the internet. They will only ever be replaced by standards; no proprietary product will ever unseat them.
Mail clients written in the eighties can still work today. Mail stores created then are still readable by today's clients. The protocols and processes involved have definitely changed, but they've _evolved_, rather than getting thrown in the trash and replaced with version 2.0, then 3.0, etc, ad infinitum, ad nauseam.
Given the choice between an evolving collaboration and reliance upon the goodwill of some stranger I can't even name, my choice will always be the former.
I disagree with some of your points, but also want to note that what I gave as email's weaknesses are frequently also strengths. I'll try to clarify the distinction.
1. Clients: There are cases in which functions which ought be standardised aren't. These are particularly problematic where archives of email from multiple systems are presented. References, quoting, and reply styles are three long-standing friction points. Various conventions for noting changes in documents -- GUI client users relying on word colour won't play well with those using text-oriented platforms. Including now a great many mobile email clients, not just mutt and pine users.
Standardisation is what makes more complex interactions possible, whether you're talking messaging formats, file formats, or nuts and bolts sizing. This makes for an interesting though likely side conversation. My point is that the lack of agreement across major families of email clients makes more complex email interactions quite painful, something I've noted for decades.
The biggest problem I'm seeing is that client tool vendors simply aren't addressing numerous areas of concern, such as those I've listed here, or working in the least toward interoperability. This is for quite understandable reasons (gaming and abusing standards for selfish gain is an old trick), but it doesn't make the resulting situation any more desirable.
2. PGP/GPG doesn't address metadata privacy at all. It's not supported by many clients (see above), and has posed very long-standing issues by way of key management and web-of-trust issues. Moxie Marlinspike is among the voices suggesting PGP may have to be swapped for something else. I'm not sure I agree with his assessment, but his isn't a voice to be trifled with.
Without encryption at the transport layer, and on a guaranteed basis, privacy protections simply don't exist. The level of concentration of email services leads to other massive concerns. Much of that is due to a lack of sufficient trust mechanisms built in at the peering level, so one problem (spam + trust) feeds another (privacy).
3. The issues of user idiosyncracies is amplified by other factors, including the client issues above. Tools to standardise formats, or convert to/from various standards, might help. My primary issue is that problems in one area of the messaging world amplify those in others. It's a mess, and neither users nor tools are helping much.
I'm aware that people aren't robots. Not all of them, at least. Providing tools that make it harder to do the wrong thing would help considerably. That's not what we have now.
4. File formats: again, it's a matter of standards. Negotiation of what is/isn't permitted, and/or required, on a given conversation, for example, might go a long ways to addressing this.
5. The directory. Addressed elsewhere. More a characteristic / non-characteristic of email as a whole, though one many proposed replacements get on the wrong side of (trying to provide a total global directory).
6. Ties in to clients, security, authentication, privacy, and a mess of other factors. It's a problem, but it's a problem grounded in virtually every other part of the email system.
7. Reputation: see above. Though I agree that it's not something that can be addressed through a central agency. Another much longer discussion.
Again: the point in my list is to note where email fails most egregiously. I like email. I've used it for thirty years. I've defended it, strongly, against numerous previous criticisms. But I've come to change my mind, in that several of the fundamental premises and capabilities of it are now fatally flawed. It needs a massive refresh.
I think it's worth adding, in the age of git sending patches by email is easier then ever - it definitely shows that git was developed by Linus with the kernel's development in mind. There is literally a `git format-patch` command which spits out a full formatted email (or emails) of your various commits, which can then be sent to a mail client to be edited and sent out. Or even easier, just use git to send the patches as email direct via `git send-email`.
The harder part is touched on in the article - email clients and email servers. All the patches sent to the mailing-list are plain text, and lots of clients or servers either mess with the plain text before sending or after receiving. And with that they also take some configuring to avoid sending attachments as base64 - which will be rejected by the kernel. Gmail thankfully doesn't mess anything up on the sever side, but the web client wraps your email to 80 characters per line making it unusable. Because of the above issues, using a separate mail client is essentially required, and setting them up can be annoying and there aren't really tons of them to choose from. I personally use `mutt`, but I can definitely understand why some wouldn't want to bother.
I remember reading that when Microsoft started contributing some code to the Linux kernel (to support Hyper-V mostly) they had to run their own Linux server in house so they could send properly formatted emails for their patches, since they had no way to send email that wouldn't be messed-up by their Outlook servers.
Outlook it probably the worst email client currently on the market and has been for the all of it's existence.
It is my belief of the issue at lot of people have with email stems from Outlook. One example is the weird instance of top posting has made it hard to read many conversations and fostered a mentality of firing of quick response, reducing Outlook/email to a poor mans IM client.
There's a ton of improvements that could be made to Outlook to make it better.
If you view it in an ascii-only mail client you will see plenty of places where an ascii character could have been used but instead a visually similar code point has been chosen. Things like dashes, single and double quote characters.
If you use github, you can also utilize git am to pull changes locally - i.e. add .patch to the end of a pull request url, navigate to the resulting url, copy the new url, then run curl <insert url> | git am -3
The article totally missed the mark on Gerrit. I think the heavy user is now OpenStack and not Android...
The article claims that Gerrit is just a small part, but if used fully it really isn't. It can be used to track the entire patch lifecycle. Which LKML doens't do via email.. because it isn't very good at it... it uses 'patchwork'.
OpenStack uses Gerrit to manage 537 git repositories. In the last year, 86,027 changesets were merged in the last year out of 111,292 commits. [0]
The real values are the smart searching capability (with email subscription to that search),integration with CI, inline code reviews.. simple rebasing, acls and easy digestion who reviewed.
I find the idea that a technology should be replaced simply because it is old to be very irksome. Those developers out there blindly contributing to the trend of replacing "tried and true" with "new and shiny" really need to take a step back and gain some perspective.
Email works great for the vast, vast majority of users.
Web development is the absolute worst at this. None of the technology is new, whatsoever (mostly stealing from Lisp, rebranding it, and doing it wrong or calling MVC by yet-another name). It's impossible to quantitatively state that the new tools we use today are any better than the tools we just tossed out yesterday. Because no one became a master at the tools of yesterday. There is no basis for comparison. No expertise. Just the eternal trend following.
While I agree, the opposite is also an issue. Developers which either look down upon anything new as "pointless" or in some cases actively try to stop improvements.
Looking at the kernel dev system, it works great, but it has its share of problems. I've never even thought about contributing to the kernel because of the work involved to just submit a patch, that process can be improved.
Making it easier for newcomers, and updating some of the workflow to be more aligned with current tools could really help.
I think it's a deliberate barrier to entry: they're basically saying "if you can't be bothered to learn how to do it, we don't want your contributions."
Linus occasionally rants about some of the crap that gets in, and I have a feeling he certainly doesn't want more, which would happen if the barrier was lowered. Here's a somewhat recent example:
Probably you are right, though in the case you linked the barrier was clearly insufficient. And OTOH, I have seen many cases where actually sane one-time contributors had to spend unreasonable time changing trivial patches to match the guidelines.
[RFC PATCH] cmdline: Hide "debug" from /proc/cmdline
It has come to our attention that a system running a specific user
space init program will not boot if you add "debug" to the kernel
command line.
Lol. I sometimes get disgusted by the kind of crap people merge, but it's nice that at least this one got the ridicule it deserved.
I really do wonder what it is with Sievers. The handing of udev went into a nosedive after GregKH handed him the maintainership. Yet GregKH seems to trust him completely and Torvalds for some reason trust GregKH.
It really makes me worry about the future of the kernel once Torvalds decides that he has had enough.
I will note that contributing to GitHub is pretty much just as complicated, and requires just as many steps and git commands. The difference is that folks are used to contributing to GitHub.
And that's an important difference. I feel that projects should allow newcomers to contribute through multiple channels. For tiny patches from newcomers, it doesn't really hurt to let them make patches on github, go through review (without annoying other folks with nitfix review emails), and mail the final patch to the list for them. Of course, as they start to contribute more, nudge them towards the "real" patch process. This moves them towards contributing the regular way without the process being one more barrier in the way of entry.
I've mentioned this in http://manishearth.github.io/blog/2016/01/03/making-your-ope... -- you can tailor your process for newcomers. Your current process is probably great for power users but might be complicated for newcomers, but at the same time a lot of what makes the process great really isn't necessary for the patches that most newcomers contribute.
Of course, all this works when the project actually cares about helping newcomers. As mentioned in the other comments, it seems like Linux doesn't care about this; it prefers to restrict itself to contributors who can (and want to) figure it out on their own. This could end up filtering out smart people who could have figured it out (but found better uses of their time), but that's their choice.
Not to say that projects which don't do this don't care about this. GDB has a pretty complicated process, but they're also very helpful to newcomers. I might work on providing an alternate workflow or a mentoring process at some point. Firefox is similar; the bugzilla-based workflow can be new and tricky, but there's mentorship. (Another thing I may work on improving at some point)
But if their traditional method is SVN, then there is a bigger reason to have some git element available. Linux already uses git, and has less incentive to add in a "git, the hard way" option.
Well, patch emailing can be done from any vcs, as long as there is something to clone from :)
One of the main reasons git is popular is because of github, and consequently there are lots of folks who only know the github workflow. Switching to patch emailing would be almost as new as using a new vcs for many. At least, that's my experience with folks I've mentored.
Why is people always concerned about lowering the barrier to entry just because they felt dismotivated by it?
Reviewer's time is a commodity, especially in a project like the kernel, accepting new patches is not a process that scales well when you receive thousands of potentially low-quality patches.
It's a tradeoff, you get less patches but the reviewers can actually focus their efforts in accepting them.
In most professions, quality is enforced by some sort of autocratic or bureaucratic process. Software seems to tend more to the autocratic, au least outside of enterprise emvironments
"Some systems, like Outlook, will uniformly corrupt patches; as a result, companies doing kernel development tend to keep a Linux machine that they can use to send patches in a corner somewhere." Isn't a Linux desktop also convenient for the development itself?
I developed a series of patches for the RPi kernel fork. I use the Pi headless, and generally access it from a Windows machine.
I never tried to send those patches upstream - and the Pi fork uses Github for such things - but I'm entirely confident that if I tried to paste those patches into an email client somewhere along the line, I'd get an upstream maintainer pointing out that magical line breaks blew something up somewhere.
When I was at Google, gerrit was indeed used internally. Things may have changed in the last 18months, but moving off the old tool to Gerrit was such a huge project that I'd be surprised if they'd moved on to something else.
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 keep using email is "Email works just as well as GitHub, and we've already been using email, so we might as well continue using it." Which is a good reason on it's own - there's no reason to try and come up with problems with GitHub. (Again, not saying GitHub is perfect, but I don't think the reasons he gave were particularly valid.)
I don't really feel that you being a millennial or using vim is relevant.
I have no idea how you would go about getting github to implement whatever functionality is desired and even so would come with the following disadvantages
-- Requiring a chrome extension limiting people to using chrome + a singular website vs any email client under the sun
-- wouldn't work offline
-- Presumably it would be more challenging for sight impaired individuals to use a js heavy website vs their email. They stated they had existing contributors who were so impaired.
-- Since people still presumably do a lot of discussion via email it would mean using at minimum github AND email some of which would refer back and forth to other discussions.
-- Relying on github would require tying free software infrastructure to a single non free software tool. Recalling bitkeeper this didn't go well last time.
-- Hosted github costs additional money.
-- The primary and perhaps only benefit would be making it easier for people to come in off the street and drop patches with minimal effort but this would actually cost effort to manage and the kind of individual who can't or likely wont figure out how to use existing infrastructure may not be an optimal contributor in any case.
Basically your solution involves not only effort to create tools that don't exist, the cooperation of a third party, but the end result would almost certainly be objectively worse in a number of ways.
I feel like you didn't really address any of the things the actual expert on the matter said and just hand waved his entire argument away.
Catehorically not using extensions, regardless of their permissions system, sounds less like "security concerns" and more like "fear rooted in ignorance." Continuing to use some of them (ad blockers), regardless of said "security concerns", sounds like cognitive dissonance.
> that could easily be solved by adding things to GitHub or using a chrome extension
I don't believe "adding things to GitHub" is easy unless you're the GitHub product manager. Also requiring some extensions would mean auto-verifying all the requirements on submitted PRs and half of them ending up with "redo it our way and submit again".
Not impossible, but likely annoying to contributors and spammy for anyone receiving PRs.
Just try to use GitHub Enterprise for 400 or more users. You get a bare metal image of the virtual machine with no replication, load balancing, etc. Nothing more for a huge price. I don't know how they scaling public version.
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.
I like to think that Linux kernel developers master most of the tools they use, especially maintainers who have power to accept patches.
From my own perspective and in different contexts, I can tell that email can be as efficient as it can be inefficient and that depends mostly on its users.
> Between email and lisp, is there any other system that you can find in any sufficiently large system?
Make. How many systems try really really hard to just update the things that need to be changed in an output store from a different input store using a serial number? Nah, just use the date. That's almost like a serial number, isn't it? Except for those handful of things for which we couldn't be bothered to set up the dependencies correctly - those get updated every time. It won't be that expensive to refresh just a handful every run...
Email is great and I can see why they continue to use it, but there is a danger of being blinkered. Saying that GitHub reinvented email because they have comment threads is... almost trolling. Especially when also saying email integrates well with patchwork (presumably written due to the inability of email to handle issue/PR tracking).
One thing I've always wondered is why email based patch submission and review was never done via a newsgroup over NNTP.
One advantage a newsgroup has over an email list is that you don't have to set up filters in your email client, and that every message posted doesn't have to be specifically CC'd to a certain group of people. Also, it's much easier to browse past posts.
Currently this can be done via the gmane NNTP gateway for the kernel and git mailing lists, but I can't see a good reason why a newsgroup wouldn't be preferred over a mailing list.
Is Gerrit really that terrible? I do agree that clicking through each file is a waste, but I love the ability to work on several different reviews and keep track of their different build statuses.
Also, where I use it we have different levels of requirements for different branches (more people usually need to approve reviews on soon-to-be-released point branches). We use it for a large project in MLOCs but relatively few developers (less than a hundred). I can't see it would work for 4000 devs at all, though.
Perhaps my experience is made worse by the fact that our Gerrit servers (perhaps about 5000 users) are so painfully slow that it can take a minute to display a page. Multiply that by the number of files touched in a patch to get a whole review done.
Then add all this non-vanilla Git extensions like "Change-Id" lines in commit messages and Gerrit/Repo's awkward idea of branches spanning multiple repositories.
All this makes it difficult to deal with multiple patches that make a "feature", ie. a feature branch. Something that should be trivial in Git is made really difficult by Gerrit.
Our team of 10 thinks Gerrit is great. I don't know how these other people are using Gerrit, but I don't recognize their description at all. Gerrit is very convenient if you take code reviews seriously.
I do agree that clicking through each file is a waste
Well, firstly it is simply not true that you need to do that (you can accept/reject a review without having viewed any file at all), but secondly I'm totally fine with pressing ] 20 times for a review that touches 20 files. If the diff was a single unified diff, I'd have to press page-down a few times and those few keystrokes don't make much of a difference compared to the time taken to actually review code.
Article says:
Gerrit, he said, makes patch submission quite hard
But without any explanation for why.
It is hard to do local testing of patches in Gerrit,
It's easy to checkout a review to its own branch, so why do they feel that way?
All discussions are done through a web interface.
Yeah, well, if using a web interface is a problem for you, then of course Gerrit is not a good tool for you. If you think the web interface doesn't add anything, then Gerrit is not a good tool for you. But those are not shortcomings of Gerrit, but simply a mismatch between your preferred workflow and your preferred way of interacting with code reviews.
> Article says:
> Gerrit, he said, makes patch submission quite hard
> But without any explanation for why.
You need to add hooks to inject a Change-Id into every commit, and be careful that they're still "fresh" (e.g. you cannot reuse one from an abandoned branch if you want to re-submit it).
And you must push a diff to the server so it can be submitted to Gerrit. If your feature branch is up-to-date (you just force-pushed it), you cannot submit the same commit to Gerrit.
And it gets worse when you have developers who rely on an IDE to get work done – the IntelliJ plugin for Gerrit is pretty buggy (I think it's okay for submitting now, but reviewing was still frustrating last month).
If your feature branch is up-to-date (you just force-
pushed it), you cannot submit the same commit to Gerrit.
It sounds to me like this is where it's going wrong. If Gerrit is not also hosting your 'origin' git repositories and acting as a gatekeeper for any commit to be added to it, then you are working against the system.
I don't see the problem with hooks and we rarely have problems with Change-Ids not being 'fresh' anymore (that sounds like the result of a suboptimal workflow).
Bugs in plugins are of course not a good reason to say Gerrit isn't very good. That's like saying git itself sucked when the IntelliJ plugin for git still had annoying bugs.
> If Gerrit is not also hosting your 'origin' git repositories and acting as a gatekeeper for any commit to be added to it, then you are working against the system.
It is/was. But if I push my work to origin/features/foo, then push the same commit to refs/for/master, it will not create a review because no new commit has been introduced. At least that's my experience and it is (kind of) spelled out like that in the manual [1]: "Each new commit uploaded by the git push client will be converted into a change record on the server."
I've only tried this a couple of times, so hopefully that was a case of PEBKAC.
> Bugs in plugins are of course not a good reason to say Gerrit isn't very good.
Services like GitLab/GitHub/Bitbucket work with every git GUI out of the box, because all you need to do is to push branches and then open a web browser. With Gerrit, you need to know how to push to a magic URL (especially if you want to specify a topic or message), or you'll need a plugin. I don't blame Gerrit for the low quality of the IntelliJ plugin, but for needing a plugin in the first place.
Gerrit does have "one commit, one review", but - that's not a bad thing. If a change is well written and structured, merging the first in the chain without the second+ is both harmless and is progress towards the end goal.
There's also patch chains in Gerrit, so you can see the X commits that make up the full change, and the second+ cannot be merged before the first.
I was mostly thinking about the simple matter of scaling the resources and maintenance crew to tackle 4000 devs. But my biggest concern about it is that it introduces centralization into the workflow. I do truly love Gerrit, but I get a bit worried about keeping a lot of important stuff in a centralized and not so transparent database.
For continued decentralized operations something like https://github.com/google/git-appraise looks good. It's like Fossil-SCM's distributed tickets but for code review. It can also mirror to Gihtub and Phabricator and has a web interface too. Most importantly it doesn't break the decentralized aspect of git.
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 can't be downloaded locally for offline work.
This would allow doing code reviews and managing issues e.g. while commuting in a train. And everything would be pretty fast compared to waiting for a web page to load for every file you want to review and connecting to a server for every comment you write.
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 goal like git shouldn't enhance a meaning to an object type.
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.
Would an offline code review application work? something which synced the comments on internet access resuming? I am planning something similar with https://about.preen.ly
Amusingly, the article references Kubernetes and its growing pains a couple times, but fails to mention that it adopted Reviewable (on top of GitHub) for doing more complicated code reviews. I don't know if Reviewable would scale to kernel development -- and it certainly doesn't support offline work, etc. -- but at least Kubernetes seems to be doing all right with it.
I don't have anything against e-mail but I don't get what's wrong with Gerrit either [1]. We used it on several projects and it was pretty transparent to the work flow.
[1]except for some Java gc issues that required the process to be restarted every now and then - pretty annoying though
For Github organizations, can't you forward notifications to a mailing list? Then everyone on the mailing list can see everyone's comments and respond through email but you still get to keep Github and all of its advantages.
Or people can just subscribe to a repo. Github provides pretty decent tools for filtering these via mail filters, too (sadly the on-site github notifications aren't as fine grained). GKHs assertion that you can't follow threads via email is false.
Are there any good references online about how to switch from Github-based collaboration to one based on email and patches? I'd like to give it a try and see how it feels.
Put mailman/majordomo and cgit/gitweb on a server, and a little front page for the project if you like. Use spamassassin with mailman, restrict allowed mail mime types to plain text and patches. Maybe use one of those tools that pick patches up from your mbox. Quilt is a good patch manager. I'd use emacs org mode for issues and todos.
As always, it's worth pointing out that this is just about the Linux kernel. Different scale, different developer community, different code structure, different testing/CI methodology (i.e. practically none) than just about every other project out there. Email works for them - great. Other things work for other people - also great. Theirs is one interesting data point, but that's all it is.
>As always, it's worth pointing out that this is just about the Linux kernel. Different scale, different developer community, different code structure, different testing/CI methodology (i.e. practically none) than just about every other project out there.
Eh? Patches on mailing lists is the "traditional" way for open source projects to operate. Many projects "still" do things this way - indeed I wish more projects did, for the reasons outlined in this article!
You're trying to refute a much stronger claim than I actually made. I was pointing out these differences to explain why what's best for the Linux kernel might not be best for another project. I wasn't saying email is bad, that it couldn't be the best for any other project, etc. The space of projects for which email is a good choice might be larger than just the Linux kernel, but it's much much smaller than the whole space of open-source projects as well. Given this community's tendency to cargo-cult whatever the highest-profile projects do without thinking about how different circumstances might affect applicability, I thought it was worth highlighting.
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 understood this - slack and GitHub have a lot more distraction with their social media components.
I see the day coming soon when in order to work with other people I'll need to find and install one of the x tens of IM clients. The day when I can't find anything because it is in a million places and its real hard to search 10 years of conversation when messages don't have basic metadata like a subject. :(