Lines Matching +full:off +full:- +full:by
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
122 ``Message-ID`` header of the message without the surrounding angle brackets.
147 characters of the SHA-1 ID, and the one line summary. Do not split the tag
163 $ git log -1 --pretty=fixes 54a4f0239f2e
169 ---------------------
183 change that can be verified by reviewers. Each patch should be justifiable
201 Style-check your changes
202 ------------------------
205 found in Documentation/process/coding-style.rst.
211 another -- in this case you should not modify the moved code at all in
223 - ERROR: things that are very likely to be wrong
224 - WARNING: things requiring careful review
225 - CHECK: things requiring thought
232 ------------------------------------
240 (akpm@linux-foundation.org) serves as a maintainer of last resort.
242 linux-[email protected] should be used by default for all patches, but the
246 Many kernel-related lists are hosted at kernel.org; you can find a list
247 of them at https://subspace.kernel.org. There are kernel-related lists
251 Linux kernel. His e-mail address is <torvalds@linux-foundation.org>.
252 He gets a lot of e-mail, and, at this point, very few patches go through
253 Linus directly, so typically you should do your best to -avoid-
254 sending him e-mail.
260 Documentation/process/security-bugs.rst.
263 toward the stable maintainers by putting a line like this::
267 into the sign-off area of your patch (note, NOT an email recipient). You
268 should also read Documentation/process/stable-kernel-rules.rst
271 If changes affect userland-kernel interfaces, please send the MAN-PAGES
272 maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at
274 into the manual pages. User-space API changes should also be copied to
275 linux-[email protected].
279 -------------------------------------------------------------------
283 developer to be able to "quote" your changes, using standard e-mail
286 For this reason, all patches should be submitted by e-mail "inline". The
287 easiest way to do this is with ``git send-email``, which is strongly
288 recommended. An interactive tutorial for ``git send-email`` is available at
289 https://git-send-email.io.
291 If you choose not to use ``git send-email``:
295 Be wary of your editor's word-wrap corrupting your patch,
296 if you choose to cut-n-paste your patch.
299 Many popular e-mail applications will not always transmit a MIME
302 decreasing the likelihood of your MIME-attached change being accepted.
305 you to re-send them using MIME.
307 See Documentation/process/email-clients.rst for hints about configuring
308 your e-mail client so that it sends your patches untouched.
311 --------------------------
322 for their time. Code review is a tiring and time-consuming process, and
328 Notify people that commented on your patch about new versions by adding them to
331 See Documentation/process/email-clients.rst for recommendations on email
337 ----------------------------------------------------
338 Top-posting is strongly discouraged in Linux kernel development
346 Q: Were do I find info about this thing called top-posting?
348 Q: Why is top-posting such a bad thing?
349 A: Top-posting.
350 Q: What is the most annoying thing in e-mail?
361 Don't get discouraged - or impatient
362 ------------------------------------
369 receive comments within a few weeks (typically 2-3); if that does not
372 - possibly longer during busy times like merge windows.
380 patch or patch series - "RESEND" only applies to resubmission of a
386 -----------------------------
388 Due to high e-mail traffic to Linus, and to linux-kernel, it is common
391 e-mail discussions.
393 ``git send-email`` will do this for you automatically.
396 Sign your work - the Developer's Certificate of Origin
397 ------------------------------------------------------
401 layers of maintainers, we've introduced a "sign-off" procedure on
404 The sign-off is a simple line at the end of the explanation for the
406 pass it on as an open-source patch. The rules are pretty simple: if you
412 By making a contribution to this project, I certify that:
414 (a) The contribution was created in whole or in part by me and I
422 by me, under the same open source license (unless I am
426 (c) The contribution was provided directly to me by some other
432 personal information I submit with it, including my sign-off) is
438 Signed-off-by: Random J Developer <[email protected]>
441 This will be done for you automatically if you use ``git commit -s``.
442 Reverts should also include "Signed-off-by". ``git revert -s`` does that
447 point out some special detail about the sign-off.
449 Any further SoBs (Signed-off-by:'s) following the author's SoB are from
456 When to use Acked-by:, Cc:, and Co-developed-by:
457 ------------------------------------------------
459 The Signed-off-by: tag indicates that the signer was involved in the
464 ask to have an Acked-by: line added to the patch's changelog.
466 Acked-by: is meant to be used by those responsible for or involved with the
470 Acked-by: may also be used by other stakeholders, such as people with domain
471 knowledge (e.g. the original author of the code being modified), userspace-side
475 Acked-by: The Stakeholder <[email protected]> # As primary user
477 Acked-by: is not as formal as Signed-off-by:. It is a record that the acker
480 into an Acked-by: (but note that it is usually better to ask for an
483 Acked-by: is also less formal than Reviewed-by:. For instance, maintainers may
485 reviewed it as thoroughly as if a Reviewed-by: was provided. Similarly, a key
487 satisfied with the general approach, the feature or the user-facing interface.
489 Acked-by: does not necessarily indicate acknowledgement of the entire patch.
490 For example, if a patch affects multiple subsystems and has an Acked-by: from
498 This is the only tag which might be added without an explicit action by the
499 person it names - but it should indicate that this person was copied on the
503 Co-developed-by: states that the patch was co-created by multiple developers;
504 it is used to give attribution to co-authors (in addition to the author
505 attributed by the From: tag) when several people work on a single patch. Since
506 Co-developed-by: denotes authorship, every Co-developed-by: must be immediately
507 followed by a Signed-off-by: of the associated co-author. Standard sign-off
508 procedure applies, i.e. the ordering of Signed-off-by: tags should reflect the
510 the author is attributed via From: or Co-developed-by:. Notably, the last
511 Signed-off-by: must always be that of the developer submitting the patch.
516 Example of a patch submitted by the From: author::
520 Co-developed-by: First Co-Author <[email protected]>
521 Signed-off-by: First Co-Author <[email protected]>
522 Co-developed-by: Second Co-Author <[email protected]>
523 Signed-off-by: Second Co-Author <[email protected]>
524 Signed-off-by: From Author <[email protected]>
526 Example of a patch submitted by a Co-developed-by: author::
532 Co-developed-by: Random Co-Author <[email protected]>
533 Signed-off-by: Random Co-Author <[email protected]>
534 Signed-off-by: From Author <[email protected]>
535 Co-developed-by: Submitting Co-Author <[email protected]>
536 Signed-off-by: Submitting Co-Author <[email protected]>
539 Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
540 ----------------------------------------------------------------------
542 The Reported-by tag gives credit to people who find bugs and report them and it
545 followed by a Closes: tag pointing to the report, unless the report is not
548 reported in private, then ask for permission first before using the Reported-by
551 A Tested-by: tag indicates that the patch has been successfully tested (in
552 some environment) by the person named. This tag informs maintainers that
556 Reviewed-by:, instead, indicates that the patch has been reviewed and found
562 By offering my Reviewed-by: tag, I state that:
582 A Reviewed-by tag is a statement of opinion that the patch is an
585 offer a Reviewed-by tag for a patch. This tag serves to give credit to
587 done on the patch. Reviewed-by: tags, when supplied by reviewers known to
591 Both Tested-by and Reviewed-by tags, once received on mailing list from tester
592 or reviewer, should be added by author to the applicable patches when sending
595 Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned
596 in the patch changelog (after the '---' separator).
598 A Suggested-by: tag indicates that the patch idea is suggested by the person
609 method for indicating a bug fixed by the patch. See :ref:`describe_changes`
615 Documentation/process/stable-kernel-rules.rst.
624 --------------------------
628 formatting can be had with ``git format-patch``. The tools cannot create
640 - A ``from`` line specifying the patch author, followed by an empty
643 - The body of the explanation, line wrapped at 75 columns, which will
646 - An empty line.
648 - The ``Signed-off-by:`` lines, described above, which will
651 - A marker line containing simply ``---``.
653 - Any additional comments not suitable for the changelog.
655 - The actual patch (``diff`` output).
658 alphabetically by subject line - pretty much any email reader will
659 support that - since because the sequence number is zero-padded,
672 globally-unique identifier for that patch. It propagates all the way
679 --oneline``.
681 For these reasons, the ``summary`` must be no more than 70-75
684 succinct and descriptive, but that is what a well-written summary
687 The ``summary phrase`` may be prefixed by tags enclosed in square
751 issue. Here is an example of a well-trimmed backtrace::
763 The ``---`` marker line serves the essential purpose of marking for
766 One good use for the additional comments after the ``---`` marker is
770 ``---`` marker, please use ``diffstat`` options ``-p 1 -w 70`` so that
773 indentation). (``git`` generates appropriate diffstats by default.)
780 Please put this information **after** the ``---`` line which separates
785 the separator line, it gets automatically stripped off when applying the
790 Signed-off-by: Author <author@mail>
791 ---
792 V2 -> V3: Removed redundant helper function
793 V1 -> V2: Cleaned up coding style and addressed review comments
795 path/to/file | 5+++--
803 Explicit In-Reply-To headers
804 ----------------------------
806 It can be helpful to manually add In-Reply-To: headers to a patch
807 (e.g., when using ``git send-email``) to associate the patch with
809 the bug report. However, for a multi-patch series, it is generally
810 best to avoid using In-Reply-To: to link to older versions of the
818 -------------------------------
830 If you are using ``git format-patch`` to generate your patches, you can
831 automatically include the base tree information in your submission by
832 using the ``--base`` flag. The easiest and most convenient way to use
835 $ git checkout -t -b my-topical-branch master
836 Branch 'my-topical-branch' set up to track local branch 'master'.
837 Switched to a new branch 'my-topical-branch'
841 $ git format-patch --base=auto --cover-letter -o outgoing/ master
842 outgoing/0000-cover-letter.patch
843 outgoing/0001-First-Commit.patch
846 When you open ``outgoing/0000-cover-letter.patch`` for editing, you will
847 notice that it will have the ``base-commit:`` trailer at the very
851 $ git checkout -b patch-review [base-commit-id]
852 Switched to a new branch 'patch-review'
857 Please see ``man git-format-patch`` for more information about this
862 The ``--base`` feature was introduced in git version 2.9.0.
865 the same ``base-commit`` trailer to indicate the commit hash of the tree
868 either below the ``---`` line or at the very bottom of all other
872 and not in some internal, accessible only to you tree - otherwise it
876 -------
884 ----------
890 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
892 Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
895 <http://www.kroah.com/log/linux/maintainer-02.html>
897 <http://www.kroah.com/log/linux/maintainer-03.html>
899 <http://www.kroah.com/log/linux/maintainer-04.html>
901 <http://www.kroah.com/log/linux/maintainer-05.html>
903 <http://www.kroah.com/log/linux/maintainer-06.html>
905 Kernel Documentation/process/coding-style.rst
913 http://halobates.de/on-submitting-patches.pdf