Documentation/process/submitting-patches.rst

3 Submitting patches: the essential guide to getting your code into the kernel
9 can greatly increase the chances of your change being accepted.
18 This documentation assumes that you're using ``git`` to prepare your patches.
20 use it, it will make your life as a kernel developer and in general much
40 Describe your changes
43 Describe your problem.  Whether your patch is a one-line bug fix or
55 from upstream, so include anything that could help route your change
64 different workloads.  Describe the expected downsides of your
72 The maintainer will thank you if you write your patch description in a
76 Solve only one problem per patch.  If your description starts to get
77 long, that's a sign that you probably need to split up your patch.
89 Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
100 However, try to make your explanation understandable without external
118 there is no collision with your six-character ID now, that condition may
121 If your patch fixes a bug in a specific commit, e.g. you found an issue using
144 Separate your changes
149 For example, if your changes include both bug fixes and performance
151 or more patches.  If your changes include an API update, and a new
164 in your patch description.
166 When dividing your change into a series of patches, take special care to
169 splitting your patch series at any point; they will not thank you if you
172 If you cannot condense your patch set into a smaller set of patches,
177 Style-check your changes
180 Check your patch for basic style violations, details of which can be
184 the reviewers time and will get your patch rejected, probably
190 moving the code and your changes.  This greatly aids review of the
194 Check your patches with the patch style checker prior to submission
196 viewed as a guide, not as a replacement for human judgment.  If your code
204 You should be able to justify all violations that remain in your
208 Select the recipients for your patch
219 of your patch set.  linux-kernel@vger.kernel.org functions as a list of
222 list; your patch will probably get more attention there.  Please do not
234 Linus directly, so typically you should do your best to -avoid-
248 into the sign-off area of your patch (note, NOT an email recipient).  You
289 developer to be able to "quote" your changes, using standard e-mail
290 tools, so that they may comment on specific portions of your code.
301   Be wary of your editor's word-wrap corrupting your patch,
302   if you choose to cut-n-paste your patch.
306 attachment as plain text, making it impossible to comment on your
308 decreasing the likelihood of your MIME-attached change being accepted.
310 Exception:  If your mailer is mangling patches then someone may ask
313 See :doc:`/process/email-clients` for hints about configuring your e-mail
314 client so that it sends your patches untouched.
319 Your patch will almost certainly get comments from reviewers on ways in
320 which the patch can be improved, in the form of a reply to your email. You must
339 After you have submitted your change, be patient and wait.  Reviewers are
340 busy people and may not get to your patch right away.
345 that you have sent your patches to the right place.  Wait for a minimum of
354 convention to prefix your subject line with [PATCH].  This lets Linus
361 Sign your work - the Developer's Certificate of Origin
405 using your real name (sorry, no pseudonyms or anonymous contributions.)
528 increase the likelihood of your patch getting into the kernel.
547 which stable kernel versions should receive your fix. This is the preferred
557 that, if you have your patches stored in a ``git`` repository, proper patch
598 Bear in mind that the ``summary phrase`` of your email becomes a
693 When other developers receive your patches and start the review process,
695 should place your work. This is particularly useful for automated CI
697 the quality of your submission before the maintainer starts the review.
699 If you are using ``git format-patch`` to generate your patches, you can
700 automatically include the base tree information in your submission by
708     [perform your edits and commits]
733 If you are not using git to format your patches, you can still include
735 on which your work is based. You should add it either in the cover
738 content, right before your email signature.