Sending patches

The final destination for every change these days are the mainline repositories of the involved projects, there are no relevant linux-sunxi specific repositories anymore.

git / email based workflow
U-Boot and the Linux kernel use an email based workflow, that sends git-formatted patches in email threads to maintainers and mailing lists. The process is explained in detail in the kernel documentation, the summary here provides a quick overview.

Setting up git send-email
While you can send the emails manually, this is tedious and error-prone. Using git-send-email simplifies the process significantly. To use the tool, you need to set this up (once), to tell git about the email server to use for sending out the emails. The configuration is held in the .gitconfig file in the home directory, which can be edited with any editor. Alternatively a git command can store each setting:

git config --global sendemail.from your@email.com

The following settings (in the  section) need to be set, please replace the placeholder values with the respective values for your setup:

from = "First Last " smtpencryption = tls smtpserver = smtp.yourprovider.com smtpuser = yourusernameforsmtp smtpserverport = 587 chainreplyto = false

An example for GMail is shown in the Git documentation.

Changes structure

 * The changes need to be initially in separate patches in a repository branched of the master branch. Sometimes other kernel.org branches like linux-next/master or sunxi/sunxi/for-next are better suited.
 * Each patch should cover a single, contained change.
 * Each patch needs to have at least a Signed-off-by: line from the patch author.
 * Each patch must have a short subject with a subsystem prefix:
 * Each patch must have a descriptive commit message, explaining the reason for the patch and providing as much extra information as possible. (Trimmed) kernel error messages are OK to include. Commit messages can be elaborate.

Creating patch emails
Each patch will be send in a separate email, with the body consisting of the commit message, followed by the actual patch, inlined to the email. No attachments!

The  command takes care of creating those emails (as files), in the correct format. To prepare the emails for the 5 top patches of the current branch:

$ git format-patch -5 --cover-letter HEAD

You can change  to point to any commit, as per git syntax. If you are sending follow-up versions of the same series, add  to automatically insert the version number.

For a single patch you can omit the  option, any process related comments can go in the section after the three dashes in the email.

The created email files should be briefly inspected, and can be changed manually, although any changes should be done in the git repository, to allow re-creating the email files, for future resubmissions.

Setting up git send-email
This needs to be done only once, to tell the git tool about the email server to use for sending out the emails. The configuration is held in the .gitconfig file in the home directory, which can be edited with any editor. Alternatively a git command can store each setting:

git config --global sendemail.from your@email.com

The following settings (in the  section) need to be set, please replace the placeholder values with the respective values for your setup:

from = "First Last " smtpencryption = tls smtpserver = smtp.yourprovider.com smtpuser = yourusernameforsmtp smtpserverport = 587 chainreplyto = false

An example for GMail is shown in the Git documentation.

Sending out patch emails
You might need to install the git-email addon using your favorite package manager first.

Always send the email files to yourself first, then skim through the mails in your (web) email client. This helps to spot any errors before the patches hit the list:

$ git send-email --to your.email@provider.com --suppress--cc=all 00??-*.patch

Make sure you don't have email files from previous submission lying around in the same directory.

To learn about the recipients of the patches, use the  command in the Linux kernel (or U-Boot) source directory:

$ scripts/get_maintainer.pl 00??-*.patch

This will generate a long list of people and lists to include, along with a short rationale for their inclusion. Always include maintainers, best in To:, as they are the ones that need to deal with your patches. Include mailing lists in Cc:. Add people that you want to notify, that have been involved in the patches, that you hope to get reviews from, or that have hardware and can provide a Tested-by: tag, in Cc:. Do not include your managers or colleagues, unless they took part in the creation of the patches. If you need to notify people, put them in Bcc:, or send them a link to the thread in the mailing list archives.

Eventually send the patches out:

$ git send-email --to "Jane Maintainer " --to "Joe Maintainer " --cc guy.who.has.a.board@foo.com --cc linux-sunxi@lists.linux.dev --cc linux-kernel@vger.kernel.org --suppress-cc=all 00??-*.patch

If you add, you will receive the patches in your regular inbox, so you can copy them to your Sent folder, and follow the correct threading in your email client.

More information

 * (Old!) git send-email tricks
 * Linux Documentation: Submitting patches
 * (2010!)Youtube: Write and Submit your first Linux kernel Patch By Greg Kroah-Hartman