Create non-email method of contributing kernel patches


 * Summary: Create non-email method of contributing kernel patches
 * Proposer: Tim Bird

Description
A consistent problem for "industry" developers is problems using their e-mail client for submitting patches to mainline. In particular, many industry developers work for companies whose IT policies dictate that they use Outlook as their email client and Exchange as their email server. These two programs are problematical to use for submitting patches to the kernel. They sometimes mess up the text formatting of the patches. Often, Exchange will be configured to automatically add confidentiality notices to outgoing email. These notices conflict with the intent of publishing the patch, and emails containing such notices will not be applied by upstream maintainers.

The purpose of this project is to create a method of submitting patches to the mainline Linux kernel community that is independent of any particular e-mail client or configuration, and that thus does not suffer from the problems mentioned.

One alternative to using one's corporate email account for submitting patches is to set up a separate email account (quite often a gmail account), and submit patches from that.

The primary motivations for not just using gmail accounts are:
 * it may be desirable to have the author of the patch attributed to the corporate email address
 * it may be difficult to reach gmail (or some other external email client) from inside the corporate firewall

Ideally, this feature would be integrated into the git command suite, which is the preferred tool for working with Linux kernel source. This may be as simple as making a "git- " version of this, and putting it in the right place where git can find it. (It appears the standard git exec-path is /usr/lib/git-core). It might be possible to just add this functionality to git send-email (maybe add a flag to indicate sending the "e-mail" via a web proxy or something).

what about follow-on emails?
Note that this project is limited in scope to just the submission of patches to the community mailing lists and addresses. It does not address the further problem of responding to feedback on the patches, from those corporate-mandated email programs. That is, Outlook doesn't handle inline commenting properly, and either Outlook or Exchange may mangle the text for emails related to patch reviews. For the purpose of this project, this is considered a secondary consideration, as it is possible to use gmail or some other email account external to the company to respond to feedback.

discussion from kernel summit list
Darren Hart and others discussed this topic on the kernel summit discussion list prior to the 2015 kernel summit. Some attributes of this tooling would ease the job of maintainers, and some would ease the task for commercial developers.

Here are some features that were mentioned that would be nice to have:
 * feature available as a git command

[under construction]

Areas of research
Is it possible to specify the author of the patch when e-mailing from a different account than the author's e-mail account? That is, what does git use as the author for the commit meta-data?

List of things that go wrong
Here is a list of common problems encountered when someone sends an e-mail from a non-community-compliant e-mail client: (below each one is how to fix it)
 * patch is sent as an attachment
 * patch is sent as Content-Type: text/html
 * convert to text/
 * patch is sent with Content-Transfer-Encoding: base64
 * convert to plain text with uudecode or base64?

Here are problems I have:
 * mis-typing a person's e-mail, and having the mail go out with a bad CC: This is extremely embarassing, because everyone who responds to the e-mail gets a bounce
 * sending to the wrong people. Twice I left off the actual maintainer of a driver I was sending a fix for, because I misread the output of get_maintainers.pl.  This was also very embarassing.

proposed features

 * check that destination addresses are valid (list names spelled correctly, individuals are in MAINTAINERS file or in a git commit, or in the senders address book)
 * check the list against the addresses listed by get_maintainers.pl
 * run scripts/checkpatch.pl against the patch
 * use the mail threading options appropriate for the primary target of the patch
 * each list or maintainer has their own preferences for some submission methods - read those from MAINTAINERS and implement as desired
 * allow user to specify the author e-mail address of the patch

Related work

 * git send-email
 * RFC5321 - Simple Mail Transfer Protocol
 * There was discussion of this on the ksummit-discuss mailing list (in preparation for the 2015 kernel summit)
 * Darren Hart mentioned email tooling here: http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-July/001417.html
 * Josh Triplett mentioned some more tooling features here: http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-July/001417.html

Resources
Here is some information on how to configure outlook to use "> " to preface replied-to text in inline responses.
 * https://support.office.com/en-us/article/Reply-with-inline-comments-within-the-original-message-text-5bc44105-aeb2-49e2-8239-5aeeff52e5a7
 * Note that you set "When Replying to a message" to "prefix each line of the original message", and you set "When forwarding a message" to "prefix each lie of the original message".

Scope
Describe the expected amount of work (in person-weeks, please)

Contractor Candidates
List possible contractors for this work (can be yourself)

Comments
Some random ideas: for a response to send the email forward to the lists?
 * is it possible (or advisable) to use the list of e-mail addresses already in the kernel git tree to validate new incoming e-mails
 * idea is to encourage more newcomers. Maybe if the from address is already valid, then eliminate some validation tests?
 * need to prevent spamming the lists. Do some kind of challenge response, where an e-mail is sent to the from address, and wait
 * this is the kind of thing that should be automate-able if the person already has a patch in the kernel tree. Otherwise, use some other method of spam avoidance.