Microsoft's war on plain text email in open source
marc.info
marc.info
> “It is a fairly specific workflow that is a challenge for some newer developers to engage with. As an example, my partner submitted a patch to OpenBSD a few weeks ago, and he had to set up an entirely new mail client which didn’t mangle his email message to HTML-ise or do other things to it, so he could even make that one patch. That’s a barrier to entry that’s pretty high for somebody who may want to be a first-time contributor.”
> We assumed that Outlook was to blame. Could Microsoft fix that instead? “The question always is fix it to whose standards, because we are focused much more on business and enterprise models of clients and customers. For them we fixed it to a more HTML-based model so it really depends on who your audience is and who your target is.”
> It turned out, though, that this time Outlook was not guilty. “I think it was actually Gmail that was a barrier. And he also couldn’t do it from Apple Mail. It is just that the modern mail client has intentionally moved towards HTML,” she said.
[1] https://www.theregister.com/2020/08/25/linux_kernel_email/
The rest of the thread is rightfully criticizing the claim for its absurdity.
In Apple Mail you can "simply" open Preferences > Composing and set "Message Format" to "Plain Text". There is also the option for each message you write to Format > Make Plain Text
But you have to know that the option exists before you can go looking for it.
When one reply to the thread says people who need HTML emails have nothing useful to say in their mails [1], and another reply says that mentioning the last name of Bill Gates will get your mail dropped by spam filters [2], I'm not sure which side(s) the absurdity is on.
Is that true? Can anyone confirm?
I've wasted an hour or so this year trying to figure out why an instance of Microsoft's sshd port of OpenSSH didn't behave as configured.
It took a while for me to realize that if you create/change the config files with Windows tooling, they will likely end up being encoded in UTF-16, which means that every second byte is a NUL character. If you have a C codebase expecting UTF-8 (like most UNIX-ish tools), that can lead to the config files just being ignored (as the tool likely hits a NUL before the first real character). In the case of sshd, you won't get any warnings or errors, either.
Old fart gatekeeping at its finest. I have a bunch of patches in Linux, I run my own email server, and I know how to send proper plain text emails... but that kind of attitude makes me want to stay away from the OpenBSD community, if I ever have a reason to interact with it.
At least the LKML Torvalds shit-slinging tirades (which shouldn't happen, but still) are usually about code, not about meta stuff like this. This is just sad.
Getting everything configured correctly was a pain. Finding out who to email for an unexpected hurdle. It took a bunch of emails back and forth until I got the format right.
I did it, but it put me off contributing again.
Would I have become a top-notch kernel developer if the process was easier? No. But I'd certainly have done some of the boring busy-work to fix minor issues.
I appreciate the workflow is set in its ways. And it probably (intentionally?) prevents a lot of casual abuse of the process. But surely there's a better way to let new people contribute?
2. call ./scripts/get_maintainer.pl -f on the file you changed
3. call git send-email -1 --cover-letter --annotate and tell it where to send the patch.
4. done
This is significantly easier than clicking a bunch of buttons on a slow Github or Gitlab instance.
If you're working with that project every day - sure, that's trivial.
If you're sending a drive-by patch useful to others, it's really in the project's best interest to make it as easy as possible. In at least one case I ended up sending an email like "This is a patch, it's in public domain now, your change process is so annoying I'm not going to spend the next hour to set it up, KTHXBYE".
But in fairness edent's problems were finding out who to address the mail to and how to format the message, not how to actually use electronic mail in the first place; and one might as well note that the procedure is also missing "learn how to plug in a keyboard" and "learn how to edit C source code", if one is going to take it that far.
There are other prerequisites. I wrote up a guide a few years ago https://shkspr.mobi/blog/2014/04/submitting-trivial-linux-ke...
5. Go back and forth discussing the patch. Let other people contribute. Significantly easier on GitHub/Lab.
> It turned out, though, that this time Outlook was not guilty. “I think it was actually Gmail that was a barrier. And he also couldn’t do it from Apple Mail. It is just that the modern mail client has intentionally moved towards HTML,” she said.
I'm curious if any sourcehut users here could explain more about sourcehut's code review tools. Do they make email-based code reviews easier?
That said, from my experiences hosting email lists, that might indirectly be the higher bar to entry. So many providers' anti-spam policies basically treat discussion lists as spam, especially if you are so bold as to have multiple subscribers who use that one list. Gods forbid one of the users manages to delete their address or let it go stale without unsubscribing first and the list software lets a single email get bounced.
I think that's actually a good thing. The person has to be interested enough to setup and learn about plain text email. Its not discrimination based on race, religion or gender identity but discrimination based on interest.
Even simple barriers to entry have positive effects. I found that the quality of bug reports on Gitlab is much higher than on Github because everyone has a Github account and will happily spam a project with a lazy bug report (me included).
Plain text emails are a pretty low bar in terms of technical challenges if one could submit Linux kernel patches.
You can have your pretty javascript applets, but please don't mess with the greybeards.
Linux needs as many people as possible. Don't scare any of those people away.
That way the user doesn't have to go out of their way to find the plain-text/html switch.
Another improvement is that mail clients implement a MarkDown or reStructuredText editing mode that will automatically generate a multipart message with both plain text and html parts. Is there any mail client like that out there?
You mean a ceremonial hurdle that has absolutely no bearing on that person's worthiness to work on a particular project?
Yes, it does sound like a fizzbuzz.
I'm not a fan of coding interviews, but being able to produce a functioning fizzbuzz should not be considered very difficult.
If someone can't do fizzbuzz, they won't be able to do things that are actual signals of ability (like finish a side project or a take-home project).
Sending the email to the correct list means directing it to the relevant subsystem maintainers. It's much more than just a patch submission method, it's a core part of their review process.
That's Microsoft's fault, but if you are at some smaller shop trying to submit a patch, it can be a royal pain in the neck, especially if the admin is a Microsoft fan and only wants to run Exchange protocol.
"Write programs to handle text streams, because that is a universal interface."
Edit: I decided to revert that switch. The article it points to is https://www.theregister.com/2020/08/25/linux_kernel_email/?.
High barrier to entry for Linux kernel patching seems like a feature, not a bug.
But what is even worse is, that most clients create extreme awful HTML, Outlook comes to mind. In a few version they put in the font-family "sans-serif" instead of sans-serif. Which meant the fall back would fail.