Lines Matching +full:e +full:- +full:mail
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.
94 Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
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.
145 If your patch fixes a bug in a specific commit, e.g. you found an issue using
147 the SHA-1 ID, and the one line summary. Do not split the tag across multiple
163 $ git log -1 --pretty=fixes 54a4f0239f2e
169 ---------------------
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-kernel@vger.kernel.org should be used by default for all patches, but the
246 Many kernel-related lists are hosted on vger.kernel.org; you can find a
247 list of them at http://vger.kernel.org/vger-lists.html. There are
248 kernel-related lists hosted elsewhere as well, though.
253 Linux kernel. His e-mail address is <torvalds@linux-foundation.org>.
254 He gets a lot of e-mail, and, at this point, very few patches go through
255 Linus directly, so typically you should do your best to -avoid-
256 sending him e-mail.
262 Documentation/process/security-bugs.rst.
269 into the sign-off area of your patch (note, NOT an email recipient). You
270 should also read Documentation/process/stable-kernel-rules.rst
273 If changes affect userland-kernel interfaces, please send the MAN-PAGES
274 maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at
276 into the manual pages. User-space API changes should also be copied to
277 linux-api@vger.kernel.org.
281 -------------------------------------------------------------------
285 developer to be able to "quote" your changes, using standard e-mail
288 For this reason, all patches should be submitted by e-mail "inline". The
289 easiest way to do this is with ``git send-email``, which is strongly
290 recommended. An interactive tutorial for ``git send-email`` is available at
291 https://git-send-email.io.
293 If you choose not to use ``git send-email``:
297 Be wary of your editor's word-wrap corrupting your patch,
298 if you choose to cut-n-paste your patch.
301 Many popular e-mail applications will not always transmit a MIME
304 decreasing the likelihood of your MIME-attached change being accepted.
307 you to re-send them using MIME.
309 See Documentation/process/email-clients.rst for hints about configuring
310 your e-mail client so that it sends your patches untouched.
313 --------------------------
324 for their time. Code review is a tiring and time-consuming process, and
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 ------------------------------------
371 one week before resubmitting or pinging reviewers - possibly longer during
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
432 personal information I submit with it, including my sign-off) is
438 Signed-off-by: Random J Developer <random@developer.example.org>
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 often used by the maintainer of the affected code when that
469 Acked-by: is not as formal as Signed-off-by:. It is a record that the acker
472 into an Acked-by: (but note that it is usually better to ask for an
475 Acked-by: does not necessarily indicate acknowledgement of the entire patch.
476 For example, if a patch affects multiple subsystems and has an Acked-by: from
485 person it names - but it should indicate that this person was copied on the
489 Co-developed-by: states that the patch was co-created by multiple developers;
490 it is used to give attribution to co-authors (in addition to the author
492 Co-developed-by: denotes authorship, every Co-developed-by: must be immediately
493 followed by a Signed-off-by: of the associated co-author. Standard sign-off
494 procedure applies, i.e. the ordering of Signed-off-by: tags should reflect the
496 the author is attributed via From: or Co-developed-by:. Notably, the last
497 Signed-off-by: must always be that of the developer submitting the patch.
506 Co-developed-by: First Co-Author <first@coauthor.example.org>
507 Signed-off-by: First Co-Author <first@coauthor.example.org>
508 Co-developed-by: Second Co-Author <second@coauthor.example.org>
509 Signed-off-by: Second Co-Author <second@coauthor.example.org>
510 Signed-off-by: From Author <from@author.example.org>
512 Example of a patch submitted by a Co-developed-by: author::
518 Co-developed-by: Random Co-Author <random@coauthor.example.org>
519 Signed-off-by: Random Co-Author <random@coauthor.example.org>
520 Signed-off-by: From Author <from@author.example.org>
521 Co-developed-by: Submitting Co-Author <sub@coauthor.example.org>
522 Signed-off-by: Submitting Co-Author <sub@coauthor.example.org>
525 Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
526 ----------------------------------------------------------------------
528 The Reported-by tag gives credit to people who find bugs and report them and it
534 reported in private, then ask for permission first before using the Reported-by
537 A Tested-by: tag indicates that the patch has been successfully tested (in
542 Reviewed-by:, instead, indicates that the patch has been reviewed and found
548 By offering my Reviewed-by: tag, I state that:
568 A Reviewed-by tag is a statement of opinion that the patch is an
571 offer a Reviewed-by tag for a patch. This tag serves to give credit to
573 done on the patch. Reviewed-by: tags, when supplied by reviewers known to
577 Both Tested-by and Reviewed-by tags, once received on mailing list from tester
581 Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned
582 in the patch changelog (after the '---' separator).
584 A Suggested-by: tag indicates that the patch idea is suggested by the person
601 Documentation/process/stable-kernel-rules.rst.
606 --------------------------
610 formatting can be had with ``git format-patch``. The tools cannot create
619 - A ``from`` line specifying the patch author, followed by an empty
622 - The body of the explanation, line wrapped at 75 columns, which will
625 - An empty line.
627 - The ``Signed-off-by:`` lines, described above, which will
630 - A marker line containing simply ``---``.
632 - Any additional comments not suitable for the changelog.
634 - The actual patch (``diff`` output).
637 alphabetically by subject line - pretty much any email reader will
638 support that - since because the sequence number is zero-padded,
651 globally-unique identifier for that patch. It propagates all the way
658 --oneline``.
660 For these reasons, the ``summary`` must be no more than 70-75
663 succinct and descriptive, but that is what a well-written summary
671 comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for
711 The ``---`` marker line serves the essential purpose of marking for
714 One good use for the additional comments after the ``---`` marker is
718 ``---`` marker, please use ``diffstat`` options ``-p 1 -w 70`` so that
728 Please put this information **after** the ``---`` line which separates
738 Signed-off-by: Author <author@mail>
739 ---
740 V2 -> V3: Removed redundant helper function
741 V1 -> V2: Cleaned up coding style and addressed review comments
743 path/to/file | 5+++--
762 issue. Here is an example of a well-trimmed backtrace::
773 Explicit In-Reply-To headers
774 ----------------------------
776 It can be helpful to manually add In-Reply-To: headers to a patch
777 (e.g., when using ``git send-email``) to associate the patch with
778 previous relevant discussion, e.g. to link a bug fix to the email with
779 the bug report. However, for a multi-patch series, it is generally
780 best to avoid using In-Reply-To: to link to older versions of the
783 helpful, you can use the https://lore.kernel.org/ redirector (e.g., in
788 -------------------------------
796 If you are using ``git format-patch`` to generate your patches, you can
798 using the ``--base`` flag. The easiest and most convenient way to use
801 $ git checkout -t -b my-topical-branch master
802 Branch 'my-topical-branch' set up to track local branch 'master'.
803 Switched to a new branch 'my-topical-branch'
807 $ git format-patch --base=auto --cover-letter -o outgoing/ master
808 outgoing/0000-cover-letter.patch
809 outgoing/0001-First-Commit.patch
812 When you open ``outgoing/0000-cover-letter.patch`` for editing, you will
813 notice that it will have the ``base-commit:`` trailer at the very
817 $ git checkout -b patch-review [base-commit-id]
818 Switched to a new branch 'patch-review'
823 Please see ``man git-format-patch`` for more information about this
828 The ``--base`` feature was introduced in git version 2.9.0.
831 the same ``base-commit`` trailer to indicate the commit hash of the tree
834 either below the ``---`` line or at the very bottom of all other
839 ----------
845 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
847 Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
850 <http://www.kroah.com/log/linux/maintainer-02.html>
852 <http://www.kroah.com/log/linux/maintainer-03.html>
854 <http://www.kroah.com/log/linux/maintainer-04.html>
856 <http://www.kroah.com/log/linux/maintainer-05.html>
858 <http://www.kroah.com/log/linux/maintainer-06.html>
860 NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
863 Kernel Documentation/process/coding-style.rst
865 Linus Torvalds's mail on the canonical patch format:
871 http://halobates.de/on-submitting-patches.pdf