Documentation/process/5.Posting.rst

13 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`,
14 :ref:`Documentation/process/submitting-drivers.rst  <submittingdrivers>`
15 and :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`.
19 ------------
25 consider posting in-progress work, or even making a git tree available so
31 patches which are known to be half-baked, but those who do will come in
32 with the idea that they can help you drive the work in the right direction.
36 -----------------------
41  - Test the code to the extent that you can.  Make use of the kernel's
43    combinations of configuration options, use cross-compilers to build for
46  - Make sure your code is compliant with the kernel coding style
49  - Does your change have performance implications?  If so, you should run
53  - Be sure that you have the right to post the code.  If this work was done
54    for an employer, the employer likely has a right to the work and must be
62 -----------------
70 Linus's git tree.  When basing on mainline, start with a well-known release
71 point - a stable or -rc release - rather than branching off the mainline at
74 It may become necessary to make versions against -mm, linux-next, or a
80 Only the most simple changes should be formatted as a single patch;
86  - The patch series you post will almost certainly not be the series of
90    discrete, self-contained changes, not the path you took to get to those
93  - Each logically independent change should be formatted as a separate
96    conceptually small and amenable to a one-line description.  Each patch
100  - As a way of restating the guideline above: do not mix different types of
106  - Each patch should yield a kernel which builds and runs properly; if your
113  - Do not overdo it, though.  One developer once posted a set of edits
114    to a single file as 500 separate patches - an act which did not make him
115    the most popular person on the kernel mailing list.  A single patch can
119  - It can be tempting to add a whole new infrastructure with a series of
133 -------------------------------
140  - An optional "From" line naming the author of the patch.  This line is
144  - A one-line description of what the patch does.  This message should be
155  - A blank line followed by a detailed description of the contents of the
159  - One or more tag lines, with, at a minimum, one Signed-off-by: line from
163 changelogs is a crucial but often-neglected art; it's worth spending
172 most direct and concise way possible.
175 for the change as well as possible given the one-line constraint.  The
191  - The patch itself, in the unified ("-u") patch format.  Using the "-p"
198 pass it to diff with the "-X" option.
203 the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
209 	tag: Full Name <email address>  optional-other-stuff
213  - Signed-off-by: this is a developer's certification that he or she has
214    the right to submit the patch for inclusion into the kernel.  It is an
216    which can be found in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
219  - Co-developed-by: states that the patch was co-created by several developers;
220    it is a used to give attribution to co-authors (in addition to the author
222    Every Co-developed-by: must be immediately followed by a Signed-off-by: of
223    the associated co-author.  Details and examples can be found in
224    :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
226  - Acked-by: indicates an agreement by another developer (often a
230  - Tested-by: states that the named person has tested the patch and found
233  - Reviewed-by: the named developer has reviewed the patch for correctness;
234 …see the reviewer's statement in :ref:`Documentation/process/submitting-patches.rst <submittingpatc…
237  - Reported-by: names a user who reported a problem which is fixed by this
242  - Cc: the named person received a copy of the patch and had the
250 -----------------
255  - Are you sure that your mailer will not corrupt the patches?  Patches
256    which have had gratuitous white-space changes or line wrapping performed
261    :ref:`Documentation/process/email-clients.rst <email_clients>` has some
264  - Are you sure your patch is free of silly mistakes?  You should always
282  - The maintainer(s) of the affected subsystem(s).  As described earlier,
285  - Other developers who have been working in the same area - especially
289  - If you are responding to a bug report or a feature request, copy the
292  - Send a copy to the relevant mailing list, or, if nothing else applies,
293    the linux-kernel list.
295  - If you are fixing a bug, think about whether the fix should go into the
314 	[PATCH nn/mm] subsys: one-line description of the patch
326 In general, the second and following parts of a multi-part patch should be
330 are using git, please stay away from the --chain-reply-to option to avoid