Speaking as someone who has gotten a small number of patches into the kernel (via email, naturally), the implication that sending patches by email requires no additional accounts or tools or learning is a false one.

Sending patches by email requires an email setup that works. You have, loosely, three options: you can send it in your normal client, you can set up `git send-email` to submit over SMTP, or you can set up `git imap-send` to get it into your normal client's drafts folder. If you choose the first one, your client has to preserve spaces, tabs, linebreaks, and everything else byte-for-byte intact. If you choose the second two, git has to be able to auth to your email server, and nothing else along the way can break the byte-for-byte integrity of your email. Each of these is tricky in various ways; see https://www.kernel.org/doc/Documentation/process/email-clien... for a discussion. (It turns out that email between humans does not depend on byte-for-byte integrity of whitespace.)

That's a lot of reading and fiddling for devs who are busy trying to produce useful output!

I recall that if your current email address is behind Microsoft Exchange, you simply can't use it for patch submission - the Exchange outgoing SMTP server does something weird with spaces, even if you don't use Outlook and connect directly to it with git send-email.

Now, certainly that might be Exchange's fault, but it doesn't change the fact that you'll need to get a new account to submit patches.

GMail also turns tabs into spaces when sending plaintext emails. I shouldn't have to set up a mail client to contribute.

Emailing patches is just as hard as making pull requests.

> preserve spaces, tabs, linebreaks, and everything else byte-for-byte intact

Hmm, sounds exactly like a use-case for Base64 and/or mime attachments. Perhaps it's worth persuing this, if there's no existing support?

Yeah, but the intent of sending patches by email is that you do code-review by hitting reply and commenting inline. If you have to import the patch into your local git repo, or build tooling for seeing it in your email client, you're strictly worse off than with a web-based code review system.

> If you have to import the patch into your local git repo, or build tooling for seeing it in your email client, you're strictly worse off than with a web-based code review system.

That's either an argument against encoding patches, or for reading email in Emacs (M-x base64-decode-region). I don't suppose many would take the latter stance ;)

> If you choose the first one, your client has to preserve spaces, tabs, linebreaks, and everything else byte-for-byte intact.

An email client which doesn't do that is broken; why would one use a primary email client which is broken?

(Yeah, it's a rhetorical question: I'm using an app client these days like everyone else, but I hate how broken it is)

Sometimes you don't have a choice and all you get is your school's or employer's email service, which can be arbitrarily crappy. Services that are crappy enough to cause problems include Gmail and Exchange, which are probably used by 90% of schools and employers. (Gmail SMTP only saves you if you can auth to Gmail SMTP; if G Suite is set up with some SSO and with app-specific passwords disabled, this can rapidly get annoying and potentially impossible.)

In which case, yes, you can set up a personal email address, but that just reduces it to the previously unsolved burden of having to set up another account just to contribute to a project.