Lines Matching full:patch
48 Describe your problem. Whether your patch is a one-line bug fix or
77 The maintainer will thank you if you write your patch description in a
81 Solve only one problem per patch. If your description starts to get
82 long, that's a sign that you probably need to split up your patch.
85 When you submit or resubmit a patch or patch series, include the
86 complete patch description and justification for it. Don't just
87 say that this is version N of the patch (series). Don't expect the
88 subsystem maintainer to refer back to earlier patch versions or referenced
89 URLs to find the patch description and put that into the patch.
90 I.e., the patch (series) and its description should be self-contained.
92 probably didn't even receive earlier versions of the patch.
95 instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
116 can be found on the web, add 'Link:' tags pointing to it. If the patch is a
133 patch as submitted.
135 In case your patch fixes a bug, use the 'Closes:' tag with a URL referencing
145 If your patch fixes a bug in a specific commit, e.g. you found an issue using
171 Separate each **logical change** into a separate patch.
179 group those changes into a single patch. Thus a single logical change
180 is contained within a single patch.
182 The point to remember is that each patch should make an easily understood
183 change that can be verified by reviewers. Each patch should be justifiable
186 If one patch depends on another patch in order for a change to be
187 complete, that is OK. Simply note **"this patch depends on patch X"**
188 in your patch description.
191 ensure that the kernel builds and runs properly after each patch in the
193 splitting your patch series at any point; they will not thank you if you
196 If you cannot condense your patch set into a smaller set of patches,
204 Check your patch for basic style violations, details of which can be
207 the reviewers time and will get your patch rejected, probably
212 the same patch which moves it. This clearly delineates the act of
217 Check your patches with the patch style checker prior to submission
228 patch.
231 Select the recipients for your patch
235 any patch to code that they maintain; look through the MAINTAINERS file and the
256 If you have a patch that fixes an exploitable security bug, send that patch
258 to allow distributors to get the patch out to users; in such cases,
259 obviously, the patch should not be sent to any public lists. See also
267 into the sign-off area of your patch (note, NOT an email recipient). You
272 maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at
295 Be wary of your editor's word-wrap corrupting your patch,
296 if you choose to cut-n-paste your patch.
298 Do not attach the patch as a MIME attachment, compressed or not.
313 Your patch will almost certainly get comments from reviewers on ways in
314 which the patch can be improved, in the form of a reply to your email. You must
325 version, add a ``patch changelog`` to the cover letter or to individual patches
328 Notify people that commented on your patch about new versions by adding them to
365 busy people and may not get to your patch right away.
374 It's also ok to resend the patch or the patch series after a couple of
377 [PATCH Vx RESEND] sub/sys: Condensed patch summary
380 patch or patch series - "RESEND" only applies to resubmission of a
381 patch or patch series which have not been modified in any way from the
385 Include PATCH in the subject
389 convention to prefix your subject line with [PATCH]. This lets Linus
405 patch, which certifies that you wrote it or otherwise have the right to
406 pass it on as an open-source patch. The rules are pretty simple: if you
450 people handling and transporting the patch, but were not involved in its
451 development. SoB chains should reflect the **real** route a patch took
460 development of the patch, or that he/she was in the patch's delivery path.
463 patch but wishes to signify and record their approval of it then they can
464 ask to have an Acked-by: line added to the patch's changelog.
468 maintainer neither contributed to nor forwarded the patch.
472 reviewers for a kernel uAPI patch or key users of a feature. Optionally, in
478 has at least reviewed the patch and has indicated acceptance. Hence patch
484 use it to signify that they are OK with a patch landing, but they may not have
486 user may not have carried out a technical review of the patch, yet they may be
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
496 If a person has had the opportunity to comment on a patch, but has not
497 provided such comments, you may optionally add a ``Cc:`` tag to the patch.
503 Co-developed-by: states that the patch was co-created by multiple developers;
505 attributed by the From: tag) when several people work on a single patch. Since
509 chronological history of the patch insofar as possible, regardless of whether
511 Signed-off-by: must always be that of the developer submitting the patch.
516 Example of a patch submitted by the From: author::
526 Example of a patch submitted by a Co-developed-by: author::
546 available on the web. The Link: tag can be used instead of Closes: if the patch
551 A Tested-by: tag indicates that the patch has been successfully tested (in
556 Reviewed-by:, instead, indicates that the patch has been reviewed and found
564 (a) I have carried out a technical review of this patch to
568 (b) Any problems, concerns, or questions relating to the patch
577 (d) While I have reviewed the patch and believe it to be sound, I
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
589 increase the likelihood of your patch getting into the kernel.
593 next versions. However if the patch has changed substantially in following
596 in the patch changelog (after the '---' separator).
598 A Suggested-by: tag indicates that the patch idea is suggested by the person
605 A Fixes: tag indicates that the patch fixes an issue in a previous commit. It
609 method for indicating a bug fixed by the patch. See :ref:`describe_changes`
614 patch candidates. For more information, please read
638 The canonical patch format
641 This section describes how the patch itself should be formatted. Note
642 that, if you have your patches stored in a ``git`` repository, proper patch
643 formatting can be had with ``git format-patch``. The tools cannot create
649 The canonical patch subject line is::
651 Subject: [PATCH 001/123] subsystem: summary phrase
653 The canonical patch message body contains the following:
655 - A ``from`` line specifying the patch author, followed by an empty
656 line (only needed if the person sending the patch is not the author).
659 be copied to the permanent changelog to describe this patch.
670 - The actual patch (``diff`` output).
681 describe the patch which that email contains. The ``summary
683 phrase`` for every patch in a whole patch series (where a ``patch
687 globally-unique identifier for that patch. It propagates all the way
689 developer discussions which refer to the patch. People will want to
691 patch. It will also be the only thing that people may quickly see
697 characters, and it must describe both what the patch changes, as well
698 as why the patch might be necessary. It is challenging to be both
703 brackets: "Subject: [PATCH <tag>...] <summary phrase>". The tags are
704 not considered part of the summary phrase, but describe how the patch
706 the multiple versions of the patch have been sent out in response to
710 If there are four patches in a patch series the individual patches may
713 they have reviewed or applied all of the patches in the patch series.
717 Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
718 Subject: [PATCH v2 01/27] x86: fix eflags tracking
719 Subject: [PATCH v2] sub/sys: Condensed patch summary
720 Subject: [PATCH v2 M/N] sub/sys: Condensed patch summary
728 From: Patch Author <author@example.com>
731 patch in the permanent changelog. If the ``from`` line is missing,
733 the patch author in the changelog.
739 From: Patch Author (Company) <author@example.com>
747 this patch. Including symptoms of the failure which the patch addresses
750 patch. The text should be written in such detail so that when read
752 details to grasp the reasoning for **why** the patch was created.
754 If a patch fixes a compile failure, it may not be necessary to include
756 someone searching for the patch can find it. As in the ``summary
785 patch handling tools where the changelog message ends.
798 example of such comments might be ``patch changelogs`` which describe
799 what has changed between the v1 and v2 version of the patch.
802 the changelog from the rest of the patch. The version information is
807 patch::
819 See more details on the proper patch format in the following
827 It can be helpful to manually add In-Reply-To: headers to a patch
828 (e.g., when using ``git send-email``) to associate the patch with
830 the bug report. However, for a multi-patch series, it is generally
832 series. This way multiple versions of the patch don't become an
835 the cover email text) to link to an earlier version of the patch series.
851 If you are using ``git format-patch`` to generate your patches, you can
862 $ git format-patch --base=auto --cover-letter -o outgoing/ master
863 outgoing/0000-cover-letter.patch
864 outgoing/0001-First-Commit.patch
867 When you open ``outgoing/0000-cover-letter.patch`` for editing, you will
872 $ git checkout -b patch-review [base-commit-id]
873 Switched to a new branch 'patch-review'
878 Please see ``man git-format-patch`` for more information about this
888 letter or in the first patch of the series and it should be placed
907 Andrew Morton, "The perfect patch" (tpp).
910 Jeff Garzik, "Linux kernel patch submission format".
911 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
928 Linus Torvalds's mail on the canonical patch format: