Lines Matching +full:non +full:- +full:descriptive
13 works, see :doc:`development-process`. Also, read :doc:`submit-checklist`
15 a driver, also read :doc:`submitting-drivers`; for device tree binding patches,
16 read :doc:`submitting-patches`.
19 If you're unfamiliar with ``git``, you would be well-advised to learn how to
24 ----------------------------
41 ---------------------
43 Describe your problem. Whether your patch is a one-line bug fix or
49 Describe user-visible impact. Straight up crashes and lockups are
54 vendor/product-specific trees that cherry-pick only specific patches
59 Quantify optimizations and trade-offs. If you claim improvements in
61 include numbers that back them up. But also describe non-obvious
62 costs. Optimizations usually aren't free but trade-offs between CPU,
85 I.e., the patch (series) and its description should be self-contained.
97 redirector with a ``Message-Id``, to ensure that the links cannot become
106 SHA-1 ID of the commit. Please also include the oneline summary of
116 SHA-1 ID. The kernel repository holds a *lot* of objects, making
118 there is no collision with your six-character ID now, that condition may
123 the SHA-1 ID, and the one line summary. Do not split the tag across multiple
139 $ git log -1 --pretty=fixes 54a4f0239f2e
145 ---------------------
177 Style-check your changes
178 ------------------------
182 :ref:`Documentation/process/coding-style.rst <codingstyle>`.
188 another -- in this case you should not modify the moved code at all in
200 - ERROR: things that are very likely to be wrong
201 - WARNING: things requiring careful review
202 - CHECK: things requiring thought
209 ------------------------------------
216 Morton (akpm@linux-foundation.org) serves as a maintainer of last resort.
219 of your patch set. linux-kernel@vger.kernel.org functions as a list of
221 to tune it out. Look in the MAINTAINERS file for a subsystem-specific
225 Many kernel-related lists are hosted on vger.kernel.org; you can find a
226 list of them at http://vger.kernel.org/vger-lists.html. There are
227 kernel-related lists hosted elsewhere as well, though.
232 Linux kernel. His e-mail address is <torvalds@linux-foundation.org>.
233 He gets a lot of e-mail, and, at this point, very few patches go through
234 Linus directly, so typically you should do your best to -avoid-
235 sending him e-mail.
241 :doc:`/admin-guide/security-bugs`.
248 into the sign-off area of your patch (note, NOT an email recipient). You
250 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
258 If changes affect userland-kernel interfaces, please send the MAN-PAGES
259 maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at
261 into the manual pages. User-space API changes should also be copied to
262 linux-api@vger.kernel.org.
270 - Spelling fixes in documentation
271 - Spelling fixes for errors which could break :manpage:`grep(1)`
272 - Warning fixes (cluttering with useless warnings is bad)
273 - Compilation fixes (only if they are actually correct)
274 - Runtime fixes (only if they actually fix things)
275 - Removing use of deprecated functions/macros
276 - Contact detail and documentation fixes
277 - Non-portable code replaced by portable code (even in arch-specific,
279 - Any fix by the author/maintainer of the file (ie. patch monkey
280 in re-transmission mode)
285 -------------------------------------------------------------------
289 developer to be able to "quote" your changes, using standard e-mail
292 For this reason, all patches should be submitted by e-mail "inline". The
293 easiest way to do this is with ``git send-email``, which is strongly
294 recommended. An interactive tutorial for ``git send-email`` is available at
295 https://git-send-email.io.
297 If you choose not to use ``git send-email``:
301 Be wary of your editor's word-wrap corrupting your patch,
302 if you choose to cut-n-paste your patch.
305 Many popular e-mail applications will not always transmit a MIME
308 decreasing the likelihood of your MIME-attached change being accepted.
311 you to re-send them using MIME.
313 See :doc:`/process/email-clients` for hints about configuring your e-mail
317 --------------------------
328 for their time. Code review is a tiring and time-consuming process, and
332 See :doc:`email-clients` for recommendations on email
336 Don't get discouraged - or impatient
337 ------------------------------------
346 one week before resubmitting or pinging reviewers - possibly longer during
351 -----------------------------
353 Due to high e-mail traffic to Linus, and to linux-kernel, it is common
356 e-mail discussions.
358 ``git send-email`` will do this for you automatically.
361 Sign your work - the Developer's Certificate of Origin
362 ------------------------------------------------------
366 layers of maintainers, we've introduced a "sign-off" procedure on
369 The sign-off is a simple line at the end of the explanation for the
371 pass it on as an open-source patch. The rules are pretty simple: if you
397 personal information I submit with it, including my sign-off) is
403 Signed-off-by: Random J Developer <random@developer.example.org>
406 This will be done for you automatically if you use ``git commit -s``.
410 point out some special detail about the sign-off.
413 When to use Acked-by:, Cc:, and Co-developed-by:
414 ------------------------------------------------
416 The Signed-off-by: tag indicates that the signer was involved in the
421 ask to have an Acked-by: line added to the patch's changelog.
423 Acked-by: is often used by the maintainer of the affected code when that
426 Acked-by: is not as formal as Signed-off-by:. It is a record that the acker
429 into an Acked-by: (but note that it is usually better to ask for an
432 Acked-by: does not necessarily indicate acknowledgement of the entire patch.
433 For example, if a patch affects multiple subsystems and has an Acked-by: from
442 person it names - but it should indicate that this person was copied on the
446 Co-developed-by: states that the patch was co-created by multiple developers;
447 it is a used to give attribution to co-authors (in addition to the author
449 Co-developed-by: denotes authorship, every Co-developed-by: must be immediately
450 followed by a Signed-off-by: of the associated co-author. Standard sign-off
451 procedure applies, i.e. the ordering of Signed-off-by: tags should reflect the
453 the author is attributed via From: or Co-developed-by:. Notably, the last
454 Signed-off-by: must always be that of the developer submitting the patch.
463 Co-developed-by: First Co-Author <first@coauthor.example.org>
464 Signed-off-by: First Co-Author <first@coauthor.example.org>
465 Co-developed-by: Second Co-Author <second@coauthor.example.org>
466 Signed-off-by: Second Co-Author <second@coauthor.example.org>
467 Signed-off-by: From Author <from@author.example.org>
469 Example of a patch submitted by a Co-developed-by: author::
475 Co-developed-by: Random Co-Author <random@coauthor.example.org>
476 Signed-off-by: Random Co-Author <random@coauthor.example.org>
477 Signed-off-by: From Author <from@author.example.org>
478 Co-developed-by: Submitting Co-Author <sub@coauthor.example.org>
479 Signed-off-by: Submitting Co-Author <sub@coauthor.example.org>
482 Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
483 ----------------------------------------------------------------------
485 The Reported-by tag gives credit to people who find bugs and report them and it
488 Reported-by tag.
490 A Tested-by: tag indicates that the patch has been successfully tested (in
495 Reviewed-by:, instead, indicates that the patch has been reviewed and found
501 By offering my Reviewed-by: tag, I state that:
521 A Reviewed-by tag is a statement of opinion that the patch is an
524 offer a Reviewed-by tag for a patch. This tag serves to give credit to
526 done on the patch. Reviewed-by: tags, when supplied by reviewers known to
530 Both Tested-by and Reviewed-by tags, once received on mailing list from tester
534 Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned
535 in the patch changelog (after the '---' separator).
537 A Suggested-by: tag indicates that the patch idea is suggested by the person
554 --------------------------
558 formatting can be had with ``git format-patch``. The tools cannot create
567 - A ``from`` line specifying the patch author, followed by an empty
570 - The body of the explanation, line wrapped at 75 columns, which will
573 - An empty line.
575 - The ``Signed-off-by:`` lines, described above, which will
578 - A marker line containing simply ``---``.
580 - Any additional comments not suitable for the changelog.
582 - The actual patch (``diff`` output).
585 alphabetically by subject line - pretty much any email reader will
586 support that - since because the sequence number is zero-padded,
599 globally-unique identifier for that patch. It propagates all the way
606 --oneline``.
608 For these reasons, the ``summary`` must be no more than 70-75
611 succinct and descriptive, but that is what a well-written summary
651 well as descriptive.
653 The ``---`` marker line serves the essential purpose of marking for patch
656 One good use for the additional comments after the ``---`` marker is for
665 If you are going to include a ``diffstat`` after the ``---`` marker, please
666 use ``diffstat`` options ``-p 1 -w 70`` so that filenames are listed from
676 Explicit In-Reply-To headers
677 ----------------------------
679 It can be helpful to manually add In-Reply-To: headers to a patch
680 (e.g., when using ``git send-email``) to associate the patch with
682 the bug report. However, for a multi-patch series, it is generally
683 best to avoid using In-Reply-To: to link to older versions of the
691 -------------------------------
699 If you are using ``git format-patch`` to generate your patches, you can
701 using the ``--base`` flag. The easiest and most convenient way to use
704 $ git checkout -t -b my-topical-branch master
705 Branch 'my-topical-branch' set up to track local branch 'master'.
706 Switched to a new branch 'my-topical-branch'
710 $ git format-patch --base=auto --cover-letter -o outgoing/ master
711 outgoing/0000-cover-letter.patch
712 outgoing/0001-First-Commit.patch
715 When you open ``outgoing/0000-cover-letter.patch`` for editing, you will
716 notice that it will have the ``base-commit:`` trailer at the very
720 $ git checkout -b patch-review [base-commit-id]
721 Switched to a new branch 'patch-review'
726 Please see ``man git-format-patch`` for more information about this
731 The ``--base`` feature was introduced in git version 2.9.0.
734 the same ``base-commit`` trailer to indicate the commit hash of the tree
737 either below the ``---`` line or at the very bottom of all other
742 ----------
748 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
750 Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
753 <http://www.kroah.com/log/linux/maintainer-02.html>
755 <http://www.kroah.com/log/linux/maintainer-03.html>
757 <http://www.kroah.com/log/linux/maintainer-04.html>
759 <http://www.kroah.com/log/linux/maintainer-05.html>
761 <http://www.kroah.com/log/linux/maintainer-06.html>
763 NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
766 Kernel Documentation/process/coding-style.rst:
767 :ref:`Documentation/process/coding-style.rst <codingstyle>`
775 http://halobates.de/on-submitting-patches.pdf