Why kernel development still uses email
lwn.net
lwn.net
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. :(
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.
Now it's more of a huge resort super island filled with lots of other people where everyone perpetually rents everything.
Too cynical?
No, too romantic. E-mail was never good enough to be decentralized, much less at the "every man" level.
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.
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.
You might even be able to do it with some custom user-side CSS.
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.
There are private networks with hundreds of active users.
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.
Answered your own question - no way to make money off it for "disruptors".
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". ;)
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 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.
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.
My knowledge about this comes from a befriended work-psychologist who worked with both, offices and factories, since the 70ies.
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.
I like to think of email as the "ledger" or repository, while your IRC alternative is your working branch.
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.
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.
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.
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.
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.
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.
I'd really like to see a further exploration of the concept. djb's essay is still only a very rough outline.
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.
[ed: never mind, my assumption was wrong:
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).
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 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.
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.
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.
More generally, email as with the Web operates as an error condition: http://deirdre.net/programming-sucks-why-i-quit/
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'm also a fan of IRC.)
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.
All it took was going through configuration and disabling some features which intuitively looked like they may mangle my emails.
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.
Another thing that Apple Mail does is to pick Unicode characters that don't map to ascii for quote and other punctuation characters.
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.
I have a git alias for this, super useful.
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.
Once setup, the workflow is super simple:
$ git commit
$ git review
$ # celebrate success
Email works great for the vast, vast majority of users.
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.
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:
[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.
It really makes me worry about the future of the kernel once Torvalds decides that he has had enough.
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)
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.
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.
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.
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 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.
And people who use extensions. Beyond ad blocker on some machines I don't use extensions on principle because of security concerns.
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.
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...
Both have strengths and weaknesses.
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.
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.
I do agree that clicking through each file is a waste
Article says:
Gerrit, he said, makes patch submission quite hard
It is hard to do local testing of patches in Gerrit,
All discussions are done through a web interface.
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.
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.
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.
[1] https://gerrit-review.googlesource.com/Documentation/user-up...
That sounds like an anethema for the kernel, where they want to review a series of tidied up commits, one per email.
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.
At that scale the project would be divided into smaller responsibility areas essentially operating on their own anyway.
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.
It seems according to this, that Github is fine for a project until it scales to such a size as you need an alternative.
So even this is agreeing that small projects should start with Github.
It would be useful to know the lower bound of users/developers at which point you need to switch to a more flexible system like email.
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.
Not sure about using json, though.
Now this project is just the first step, now it needs a code review tool (UI) on top that's good enough to match Gerrit, GitHub, etc.
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.
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.
(Disclosure: I'm the founder of Reviewable.)
[1]except for some Java gc issues that required the process to be restarted every now and then - pretty annoying though
We say we do like it, but the truth is that we don't.
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!