Lines Matching +full:non +full:- +full:descriptive
13 works, see Documentation/process/development-process.rst. Also, read
14 Documentation/process/submit-checklist.rst
17 Documentation/devicetree/bindings/submitting-patches.rst.
20 If you're unfamiliar with ``git``, you would be well-advised to learn how to
26 :ref:`Documentation/process/maintainer-handbooks.rst <maintainer_handbooks_main>`.
29 ----------------------------
46 ---------------------
48 Describe your problem. Whether your patch is a one-line bug fix or
54 Describe user-visible impact. Straight up crashes and lockups are
59 vendor/product-specific trees that cherry-pick only specific patches
64 Quantify optimizations and trade-offs. If you claim improvements in
66 include numbers that back them up. But also describe non-obvious
67 costs. Optimizations usually aren't free but trade-offs between CPU,
90 I.e., the patch (series) and its description should be self-contained.
100 SHA-1 ID of the commit. Please also include the oneline summary of
110 SHA-1 ID. The kernel repository holds a *lot* of objects, making
112 there is no collision with your six-character ID now, that condition may
124 ``Message-Id`` header of the message without the surrounding angle brackets.
139 the SHA-1 ID, and the one line summary. Do not split the tag across multiple
155 $ git log -1 --pretty=fixes 54a4f0239f2e
161 ---------------------
193 Style-check your changes
194 ------------------------
197 found in Documentation/process/coding-style.rst.
203 another -- in this case you should not modify the moved code at all in
215 - ERROR: things that are very likely to be wrong
216 - WARNING: things requiring careful review
217 - CHECK: things requiring thought
224 ------------------------------------
232 (akpm@linux-foundation.org) serves as a maintainer of last resort.
235 of your patch set. linux-kernel@vger.kernel.org should be used by default
238 subsystem-specific list; your patch will probably get more attention there.
241 Many kernel-related lists are hosted on vger.kernel.org; you can find a
242 list of them at http://vger.kernel.org/vger-lists.html. There are
243 kernel-related lists hosted elsewhere as well, though.
248 Linux kernel. His e-mail address is <torvalds@linux-foundation.org>.
249 He gets a lot of e-mail, and, at this point, very few patches go through
250 Linus directly, so typically you should do your best to -avoid-
251 sending him e-mail.
257 Documentation/admin-guide/security-bugs.rst.
264 into the sign-off area of your patch (note, NOT an email recipient). You
265 should also read Documentation/process/stable-kernel-rules.rst
268 If changes affect userland-kernel interfaces, please send the MAN-PAGES
269 maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at
271 into the manual pages. User-space API changes should also be copied to
272 linux-api@vger.kernel.org.
276 -------------------------------------------------------------------
280 developer to be able to "quote" your changes, using standard e-mail
283 For this reason, all patches should be submitted by e-mail "inline". The
284 easiest way to do this is with ``git send-email``, which is strongly
285 recommended. An interactive tutorial for ``git send-email`` is available at
286 https://git-send-email.io.
288 If you choose not to use ``git send-email``:
292 Be wary of your editor's word-wrap corrupting your patch,
293 if you choose to cut-n-paste your patch.
296 Many popular e-mail applications will not always transmit a MIME
299 decreasing the likelihood of your MIME-attached change being accepted.
302 you to re-send them using MIME.
304 See Documentation/process/email-clients.rst for hints about configuring
305 your e-mail client so that it sends your patches untouched.
308 --------------------------
319 for their time. Code review is a tiring and time-consuming process, and
326 See Documentation/process/email-clients.rst for recommendations on email
331 Don't get discouraged - or impatient
332 ------------------------------------
341 one week before resubmitting or pinging reviewers - possibly longer during
350 patch or patch series - "RESEND" only applies to resubmission of a
356 -----------------------------
358 Due to high e-mail traffic to Linus, and to linux-kernel, it is common
361 e-mail discussions.
363 ``git send-email`` will do this for you automatically.
366 Sign your work - the Developer's Certificate of Origin
367 ------------------------------------------------------
371 layers of maintainers, we've introduced a "sign-off" procedure on
374 The sign-off is a simple line at the end of the explanation for the
376 pass it on as an open-source patch. The rules are pretty simple: if you
402 personal information I submit with it, including my sign-off) is
408 Signed-off-by: Random J Developer <random@developer.example.org>
411 This will be done for you automatically if you use ``git commit -s``.
412 Reverts should also include "Signed-off-by". ``git revert -s`` does that
417 point out some special detail about the sign-off.
419 Any further SoBs (Signed-off-by:'s) following the author's SoB are from
426 When to use Acked-by:, Cc:, and Co-developed-by:
427 ------------------------------------------------
429 The Signed-off-by: tag indicates that the signer was involved in the
434 ask to have an Acked-by: line added to the patch's changelog.
436 Acked-by: is often used by the maintainer of the affected code when that
439 Acked-by: is not as formal as Signed-off-by:. It is a record that the acker
442 into an Acked-by: (but note that it is usually better to ask for an
445 Acked-by: does not necessarily indicate acknowledgement of the entire patch.
446 For example, if a patch affects multiple subsystems and has an Acked-by: from
455 person it names - but it should indicate that this person was copied on the
459 Co-developed-by: states that the patch was co-created by multiple developers;
460 it is used to give attribution to co-authors (in addition to the author
462 Co-developed-by: denotes authorship, every Co-developed-by: must be immediately
463 followed by a Signed-off-by: of the associated co-author. Standard sign-off
464 procedure applies, i.e. the ordering of Signed-off-by: tags should reflect the
466 the author is attributed via From: or Co-developed-by:. Notably, the last
467 Signed-off-by: must always be that of the developer submitting the patch.
476 Co-developed-by: First Co-Author <first@coauthor.example.org>
477 Signed-off-by: First Co-Author <first@coauthor.example.org>
478 Co-developed-by: Second Co-Author <second@coauthor.example.org>
479 Signed-off-by: Second Co-Author <second@coauthor.example.org>
480 Signed-off-by: From Author <from@author.example.org>
482 Example of a patch submitted by a Co-developed-by: author::
488 Co-developed-by: Random Co-Author <random@coauthor.example.org>
489 Signed-off-by: Random Co-Author <random@coauthor.example.org>
490 Signed-off-by: From Author <from@author.example.org>
491 Co-developed-by: Submitting Co-Author <sub@coauthor.example.org>
492 Signed-off-by: Submitting Co-Author <sub@coauthor.example.org>
495 Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
496 ----------------------------------------------------------------------
498 The Reported-by tag gives credit to people who find bugs and report them and it
501 Reported-by tag. The tag is intended for bugs; please do not use it to credit
504 A Tested-by: tag indicates that the patch has been successfully tested (in
509 Reviewed-by:, instead, indicates that the patch has been reviewed and found
515 By offering my Reviewed-by: tag, I state that:
535 A Reviewed-by tag is a statement of opinion that the patch is an
538 offer a Reviewed-by tag for a patch. This tag serves to give credit to
540 done on the patch. Reviewed-by: tags, when supplied by reviewers known to
544 Both Tested-by and Reviewed-by tags, once received on mailing list from tester
548 Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned
549 in the patch changelog (after the '---' separator).
551 A Suggested-by: tag indicates that the patch idea is suggested by the person
568 Documentation/process/stable-kernel-rules.rst.
573 --------------------------
577 formatting can be had with ``git format-patch``. The tools cannot create
586 - A ``from`` line specifying the patch author, followed by an empty
589 - The body of the explanation, line wrapped at 75 columns, which will
592 - An empty line.
594 - The ``Signed-off-by:`` lines, described above, which will
597 - A marker line containing simply ``---``.
599 - Any additional comments not suitable for the changelog.
601 - The actual patch (``diff`` output).
604 alphabetically by subject line - pretty much any email reader will
605 support that - since because the sequence number is zero-padded,
618 globally-unique identifier for that patch. It propagates all the way
625 --oneline``.
627 For these reasons, the ``summary`` must be no more than 70-75
630 succinct and descriptive, but that is what a well-written summary
676 phrase``, it is important to be both succinct as well as descriptive.
678 The ``---`` marker line serves the essential purpose of marking for
681 One good use for the additional comments after the ``---`` marker is
685 ``---`` marker, please use ``diffstat`` options ``-p 1 -w 70`` so that
695 Please put this information **after** the ``---`` line which separates
705 Signed-off-by: Author <author@mail>
706 ---
707 V2 -> V3: Removed redundant helper function
708 V1 -> V2: Cleaned up coding style and addressed review comments
710 path/to/file | 5+++--
729 issue. Here is an example of a well-trimmed backtrace::
740 Explicit In-Reply-To headers
741 ----------------------------
743 It can be helpful to manually add In-Reply-To: headers to a patch
744 (e.g., when using ``git send-email``) to associate the patch with
746 the bug report. However, for a multi-patch series, it is generally
747 best to avoid using In-Reply-To: to link to older versions of the
755 -------------------------------
763 If you are using ``git format-patch`` to generate your patches, you can
765 using the ``--base`` flag. The easiest and most convenient way to use
768 $ git checkout -t -b my-topical-branch master
769 Branch 'my-topical-branch' set up to track local branch 'master'.
770 Switched to a new branch 'my-topical-branch'
774 $ git format-patch --base=auto --cover-letter -o outgoing/ master
775 outgoing/0000-cover-letter.patch
776 outgoing/0001-First-Commit.patch
779 When you open ``outgoing/0000-cover-letter.patch`` for editing, you will
780 notice that it will have the ``base-commit:`` trailer at the very
784 $ git checkout -b patch-review [base-commit-id]
785 Switched to a new branch 'patch-review'
790 Please see ``man git-format-patch`` for more information about this
795 The ``--base`` feature was introduced in git version 2.9.0.
798 the same ``base-commit`` trailer to indicate the commit hash of the tree
801 either below the ``---`` line or at the very bottom of all other
806 ----------
812 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
814 Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
817 <http://www.kroah.com/log/linux/maintainer-02.html>
819 <http://www.kroah.com/log/linux/maintainer-03.html>
821 <http://www.kroah.com/log/linux/maintainer-04.html>
823 <http://www.kroah.com/log/linux/maintainer-05.html>
825 <http://www.kroah.com/log/linux/maintainer-06.html>
827 NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
830 Kernel Documentation/process/coding-style.rst
838 http://halobates.de/on-submitting-patches.pdf