Lines Matching +full:never +full:- +full:post +full:- +full:merge +full:- +full:rules
13 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
14 and :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`.
17 When to post
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
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
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
83 rules of thumb, however, which can help considerably:
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
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
141 but it never hurts to add it when in doubt.
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
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"
196 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
202 … 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID")
208 Link: https://example.com/somewhere.html optional-other-stuff
213 'Documentation/maintainer/configure-git.rst'.
218 Closes: https://example.com/issues/1234 optional-other-stuff
228 tag: Full Name <email address> optional-other-stuff
232 - Signed-off-by: this is a developer's certification that he or she has
235 which can be found in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
238 - Co-developed-by: states that the patch was co-created by several developers;
239 it is a used to give attribution to co-authors (in addition to the author
241 Every Co-developed-by: must be immediately followed by a Signed-off-by: of
242 the associated co-author. Details and examples can be found in
243 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
245 - Acked-by: indicates an agreement by another developer (often a
249 - Tested-by: states that the named person has tested the patch and found
252 - Reviewed-by: the named developer has reviewed the patch for correctness;
253 …see the reviewer's statement in :ref:`Documentation/process/submitting-patches.rst <submittingpatc…
256 - Reported-by: names a user who reported a problem which is fixed by this
264 - A Suggested-by: tag indicates that the patch idea is suggested by the person
268 - Cc: the named person received a copy of the patch and had the
273 Reported-by: is fine most of the time as well, but ask for permission if
278 -----------------
283 - Are you sure that your mailer will not corrupt the patches? Patches
284 which have had gratuitous white-space changes or line wrapping performed
289 :ref:`Documentation/process/email-clients.rst <email_clients>` has some
292 - Are you sure your patch is free of silly mistakes? You should always
310 - The maintainer(s) of the affected subsystem(s). As described earlier,
313 - Other developers who have been working in the same area - especially
317 - If you are responding to a bug report or a feature request, copy the
320 - Send a copy to the relevant mailing list, or, if nothing else applies,
321 the linux-kernel list.
323 - If you are fixing a bug, think about whether the fix should go into the
331 is possible to send patches directly to Linus Torvalds and have him merge
334 you will be wanting that maintainer to merge your patches. If there is no
342 [PATCH nn/mm] subsys: one-line description of the patch
354 In general, the second and following parts of a multi-part patch should be
358 are using git, please stay away from the --chain-reply-to option to avoid