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.
19 This documentation assumes that you're using ``git`` to prepare your patches.
21 use it, it will make your life as a kernel developer and in general much
45 Describe your changes
48 Describe your problem.  Whether your patch is a one-line bug fix or
60 from upstream, so include anything that could help route your change
69 different workloads.  Describe the expected downsides of your
77 The maintainer will thank you if you write your patch description in a
81 Solve only one problem per patch.  If your description starts to get
82 long, that's a sign that you probably need to split up your patch.
94 Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
112 there is no collision with your six-character ID now, that condition may
130 However, try to make your explanation understandable without external
135 In case your patch fixes a bug, use the 'Closes:' tag with a URL referencing
145 If your patch fixes a bug in a specific commit, e.g. you found an issue using
168 Separate your changes
173 For example, if your changes include both bug fixes and performance
175 or more patches.  If your changes include an API update, and a new
188 in your patch description.
190 When dividing your change into a series of patches, take special care to
193 splitting your patch series at any point; they will not thank you if you
196 If you cannot condense your patch set into a smaller set of patches,
201 Style-check your changes
204 Check your patch for basic style violations, details of which can be
207 the reviewers time and will get your patch rejected, probably
213 moving the code and your changes.  This greatly aids review of the
217 Check your patches with the patch style checker prior to submission
219 viewed as a guide, not as a replacement for human judgment.  If your code
227 You should be able to justify all violations that remain in your
231 Select the recipients for your patch
237 scripts/get_maintainer.pl can be very useful at this step (pass paths to your
255 Linus directly, so typically you should do your best to -avoid-
269 into the sign-off area of your patch (note, NOT an email recipient).  You
285 developer to be able to "quote" your changes, using standard e-mail
286 tools, so that they may comment on specific portions of your code.
297   Be wary of your editor's word-wrap corrupting your patch,
298   if you choose to cut-n-paste your patch.
302 attachment as plain text, making it impossible to comment on your
304 decreasing the likelihood of your MIME-attached change being accepted.
306 Exception:  If your mailer is mangling patches then someone may ask
310 your e-mail client so that it sends your patches untouched.
315 Your patch will almost certainly get comments from reviewers on ways in
316 which the patch can be improved, in the form of a reply to your email. You must
330 Notify people that commented on your patch about new versions by adding them to
355 to your reply. This makes responses easier to find, and saves time and
366 After you have submitted your change, be patient and wait.  Reviewers are
367 busy people and may not get to your patch right away.
372 happen, make sure that you have sent your patches to the right place.
381 Don't add "RESEND" when you are submitting a modified version of your
391 convention to prefix your subject line with [PATCH].  This lets Linus
398 Sign your work - the Developer's Certificate of Origin
577 increase the likelihood of your patch getting into the kernel.
596 which stable kernel versions should receive your fix. This is the preferred
611 that, if you have your patches stored in a ``git`` repository, proper patch
652 Bear in mind that the ``summary phrase`` of your email becomes a
792 When other developers receive your patches and start the review process,
794 commit/branch your work applies on, considering the sheer amount of
799 run a series of tests in order to establish the quality of your
802 If you are using ``git format-patch`` to generate your patches, you can
803 automatically include the base tree information in your submission by
811     [perform your edits and commits]
836 If you are not using git to format your patches, you can still include
838 on which your work is based. You should add it either in the cover
841 content, right before your email signature.