Lines Matching refs:patch
43 Describe your problem. Whether your patch is a one-line bug fix or
72 The maintainer will thank you if you write your patch description in a
76 Solve only one problem per patch. If your description starts to get
77 long, that's a sign that you probably need to split up your patch.
80 When you submit or resubmit a patch or patch series, include the
81 complete patch description and justification for it. Don't just
82 say that this is version N of the patch (series). Don't expect the
83 subsystem maintainer to refer back to earlier patch versions or referenced
84 URLs to find the patch description and put that into the patch.
85 I.e., the patch (series) and its description should be self-contained.
87 probably didn't even receive earlier versions of the patch.
90 instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
94 If the patch fixes a logged bug entry, refer to that bug entry by
95 number and URL. If the patch follows from a mailing list discussion,
103 patch as submitted.
121 If your patch fixes a bug in a specific commit, e.g. you found an issue using
147 Separate each **logical change** into a separate patch.
155 group those changes into a single patch. Thus a single logical change
156 is contained within a single patch.
158 The point to remember is that each patch should make an easily understood
159 change that can be verified by reviewers. Each patch should be justifiable
162 If one patch depends on another patch in order for a change to be
163 complete, that is OK. Simply note **"this patch depends on patch X"**
164 in your patch description.
167 ensure that the kernel builds and runs properly after each patch in the
169 splitting your patch series at any point; they will not thank you if you
172 If you cannot condense your patch set into a smaller set of patches,
180 Check your patch for basic style violations, details of which can be
184 the reviewers time and will get your patch rejected, probably
189 the same patch which moves it. This clearly delineates the act of
194 Check your patches with the patch style checker prior to submission
205 patch.
208 Select the recipients for your patch
211 You should always copy the appropriate subsystem maintainer(s) on any patch
219 of your patch set. linux-kernel@vger.kernel.org functions as a list of
222 list; your patch will probably get more attention there. Please do not
237 If you have a patch that fixes an exploitable security bug, send that patch
239 to allow distributors to get the patch out to users; in such cases,
240 obviously, the patch should not be sent to any public lists. See also
248 into the sign-off area of your patch (note, NOT an email recipient). You
259 maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at
279 - Any fix by the author/maintainer of the file (ie. patch monkey
301 Be wary of your editor's word-wrap corrupting your patch,
302 if you choose to cut-n-paste your patch.
304 Do not attach the patch as a MIME attachment, compressed or not.
319 Your patch will almost certainly get comments from reviewers on ways in
320 which the patch can be improved, in the form of a reply to your email. You must
340 busy people and may not get to your patch right away.
370 patch, which certifies that you wrote it or otherwise have the right to
371 pass it on as an open-source patch. The rules are pretty simple: if you
417 development of the patch, or that he/she was in the patch's delivery path.
420 patch but wishes to signify and record their approval of it then they can
421 ask to have an Acked-by: line added to the patch's changelog.
424 maintainer neither contributed to nor forwarded the patch.
427 has at least reviewed the patch and has indicated acceptance. Hence patch
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
439 If a person has had the opportunity to comment on a patch, but has not
440 provided such comments, you may optionally add a ``Cc:`` tag to the patch.
443 patch. This tag documents that potentially interested parties
446 Co-developed-by: states that the patch was co-created by multiple developers;
448 attributed by the From: tag) when several people work on a single patch. Since
452 chronological history of the patch insofar as possible, regardless of whether
454 Signed-off-by: must always be that of the developer submitting the patch.
459 Example of a patch submitted by the From: author::
469 Example of a patch submitted by a Co-developed-by: author::
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
503 (a) I have carried out a technical review of this patch to
507 (b) Any problems, concerns, or questions relating to the patch
516 (d) While I have reviewed the patch and believe it to be sound, I
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
528 increase the likelihood of your patch getting into the kernel.
532 next versions. However if the patch has changed substantially in following
535 in the patch changelog (after the '---' separator).
537 A Suggested-by: tag indicates that the patch idea is suggested by the person
544 A Fixes: tag indicates that the patch fixes an issue in a previous commit. It
548 method for indicating a bug fixed by the patch. See :ref:`describe_changes`
553 The canonical patch format
556 This section describes how the patch itself should be formatted. Note
557 that, if you have your patches stored in a ``git`` repository, proper patch
558 formatting can be had with ``git format-patch``. The tools cannot create
561 The canonical patch subject line is::
565 The canonical patch message body contains the following:
567 - A ``from`` line specifying the patch author, followed by an empty
568 line (only needed if the person sending the patch is not the author).
571 be copied to the permanent changelog to describe this patch.
582 - The actual patch (``diff`` output).
593 describe the patch which that email contains. The ``summary
595 phrase`` for every patch in a whole patch series (where a ``patch
599 globally-unique identifier for that patch. It propagates all the way
601 developer discussions which refer to the patch. People will want to
603 patch. It will also be the only thing that people may quickly see
609 characters, and it must describe both what the patch changes, as well
610 as why the patch might be necessary. It is challenging to be both
616 not considered part of the summary phrase, but describe how the patch
618 the multiple versions of the patch have been sent out in response to
620 comments. If there are four patches in a patch series the individual
624 the patch series.
637 patch in the permanent changelog. If the ``from`` line is missing,
639 the patch author in the changelog.
644 have led to this patch. Including symptoms of the failure which the
645 patch addresses (kernel log messages, oops messages, etc.) is
647 looking for the applicable patch. If a patch fixes a compile failure,
649 enough that it is likely that someone searching for the patch can find
653 The ``---`` marker line serves the essential purpose of marking for patch
661 here. A good example of such comments might be ``patch changelogs``
663 patch.
671 See more details on the proper patch format in the following
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
684 series. This way multiple versions of the patch don't become an
687 the cover email text) to link to an earlier version of the patch series.
699 If you are using ``git format-patch`` to generate your patches, you can
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
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
736 letter or in the first patch of the series and it should be placed
744 Andrew Morton, "The perfect patch" (tpp).
747 Jeff Garzik, "Linux kernel patch submission format".
748 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
763 NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
769 Linus Torvalds's mail on the canonical patch format: