Documentation/process/5.Posting.rst

13 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
14 and :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`.
18 ------------
24 consider posting in-progress work, or even making a git tree available so
30 patches which are known to be half-baked, but those who do will come in
31 with the idea that they can help you drive the work in the right direction.
35 -----------------------
40  - Test the code to the extent that you can.  Make use of the kernel's
42    combinations of configuration options, use cross-compilers to build for
45  - Make sure your code is compliant with the kernel coding style
48  - Does your change have performance implications?  If so, you should run
52  - Be sure that you have the right to post the code.  If this work was done
53    for an employer, the employer likely has a right to the work and must be
61 -----------------
69 Linus's git tree.  When basing on mainline, start with a well-known release
70 point - a stable or -rc release - rather than branching off the mainline at
73 It may become necessary to make versions against -mm, linux-next, or a
79 Only the most simple changes should be formatted as a single patch;
85  - The patch series you post will almost certainly not be the series of
89    discrete, self-contained changes, not the path you took to get to those
92  - Each logically independent change should be formatted as a separate
95    conceptually small and amenable to a one-line description.  Each patch
99  - As a way of restating the guideline above: do not mix different types of
105  - Each patch should yield a kernel which builds and runs properly; if your
112  - Do not overdo it, though.  One developer once posted a set of edits
113    to a single file as 500 separate patches - an act which did not make him
114    the most popular person on the kernel mailing list.  A single patch can
118  - It can be tempting to add a whole new infrastructure with a series of
132 -------------------------------
139  - An optional "From" line naming the author of the patch.  This line is
143  - A one-line description of what the patch does.  This message should be
154  - A blank line followed by a detailed description of the contents of the
158  - One or more tag lines, with, at a minimum, one Signed-off-by: line from
162 changelogs is a crucial but often-neglected art; it's worth spending
171 most direct and concise way possible.
174 for the change as well as possible given the one-line constraint.  The
190  - The patch itself, in the unified ("-u") patch format.  Using the "-p"
197 pass it to diff with the "-X" option.
201 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
207 … 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID")
213 	Link: https://example.com/somewhere.html  optional-other-stuff
218 'Documentation/maintainer/configure-git.rst'.
223 	Closes: https://example.com/issues/1234  optional-other-stuff
233 	tag: Full Name <email address>  optional-other-stuff
237  - Signed-off-by: this is a developer's certification that he or she has
238    the right to submit the patch for inclusion into the kernel.  It is an
240    which can be found in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
243  - Co-developed-by: states that the patch was co-created by several developers;
244    it is a used to give attribution to co-authors (in addition to the author
246    Every Co-developed-by: must be immediately followed by a Signed-off-by: of
247    the associated co-author.  Details and examples can be found in
248    :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
250  - Acked-by: indicates an agreement by another developer (often a
254  - Tested-by: states that the named person has tested the patch and found
257  - Reviewed-by: the named developer has reviewed the patch for correctness;
258 …see the reviewer's statement in :ref:`Documentation/process/submitting-patches.rst <submittingpatc…
261  - Reported-by: names a user who reported a problem which is fixed by this
269  - Cc: the named person received a copy of the patch and had the
274 Reported-by: is fine most of the time as well, but ask for permission if
279 -----------------
284  - Are you sure that your mailer will not corrupt the patches?  Patches
285    which have had gratuitous white-space changes or line wrapping performed
290    :ref:`Documentation/process/email-clients.rst <email_clients>` has some
293  - Are you sure your patch is free of silly mistakes?  You should always
311  - The maintainer(s) of the affected subsystem(s).  As described earlier,
314  - Other developers who have been working in the same area - especially
318  - If you are responding to a bug report or a feature request, copy the
321  - Send a copy to the relevant mailing list, or, if nothing else applies,
322    the linux-kernel list.
324  - If you are fixing a bug, think about whether the fix should go into the
343 	[PATCH nn/mm] subsys: one-line description of the patch
355 In general, the second and following parts of a multi-part patch should be
359 are using git, please stay away from the --chain-reply-to option to avoid