Lines Matching refs:patch
100 Component maintainers can be added or removed by submitting a patch to the ``MAINTAINERS`` file.
116 Tree maintainers can be added or removed by submitting a patch to the ``MAINTAINERS`` file.
180 same patch.
182 A good way of thinking about whether a patch should be split is to consider whether the change coul…
185 It is better to keep the related documentation changes in the same patch
186 file as the code, rather than one big documentation patch at the end of a
196 The first, summary, line of the git commit message becomes the subject line of the patch email.
214 …ull stop to the subject line or you will end up two in the patch name: ``dpdk_description..patch``.
218 The is generally added by ``git send-email`` or ``git format-patch``, see below.
221 An RFC patch doesn't have to be complete.
231 …important to provide enough information to allow a reviewer to understand the purpose of the patch.
247 to applying the signoff and submitting a patch.
277 tags for who reported, suggested, tested and reviewed the patch being
287 When fixing an issue found by Coverity, the patch must contain a Coverity issue ID
306 When fixing an issue raised in Bugzilla, the patch must contain
343 Sometimes a patch or patchset can depend on another one.
347 …ds-on: series-NNNNN ("Title of the series")`` or ``Depends-on: patch-NNNNN ("Title of the patch")``
349 Where ``NNNNN`` is patchwork ID for patch or series::
363 patches with ``git format-patch`` and then when everything looks okay, and the patches have been ch…
366 Here are some examples of using ``git format-patch`` to generate patches:
370 # Generate a patch from the last commit.
371 git format-patch -1
373 # Generate a patch from the last 3 commits.
374 git format-patch -3
377 git format-patch -3 -o ~/patch/
380 git format-patch -3 -o ~/patch/ --cover-letter
383 git format-patch -3 -o ~/patch/ -v 2
387 Smaller notes can be put inline in the patch after the ``---`` separator, for example::
447 devtools/checkpatches.sh ~/patch/
519 git send-email --to [email protected] --cc [email protected] 000*.patch
523 git send-email --to-cmd ./devtools/get-maintainer.sh --cc [email protected] 000*.patch
527 git send-email --to [email protected] 000*.patch
531 If the patch is in relation to a previous email thread you can add it to the same thread using the …
533 git send-email --to [email protected] --in-reply-to <[email protected]> 000*.patch
535 The Message ID can be found in the raw text of emails or at the top of each Patchwork patch,
536 `for example <https://patches.dpdk.org/patch/7646/>`_.
537 Shallow threading (``--thread --no-chain-reply-to``) is preferred for a patch series.
541 …committers may send patches directly with ``git send-email`` without the ``git format-patch`` step.
548 Sometimes a maintainer or contributor wishes, or can be asked, to send a patch
550 In this case the patch(es) should be sent to ``[email protected]``,
554 please specify exactly which branch(es) the patch is for
564 number of ways to indicate that you have checked a patch on the mailing list.
570 To indicate that you have interacted with a patch on the mailing list you
571 should respond to the patch in an email with one of the following tags:
589 ``Reviewed-by:`` is a strong statement_ that the patch is an appropriate state
592 thorough reviews will increase the likelihood of the patch getting merged.
595 the preparation of the patch but wishes to signify and record their acceptance
598 ``Tested-by:`` indicates that the patch has been successfully tested (in some
603 ``Suggested-by:`` indicates that the patch idea was suggested by the named
608 Steps to getting your patch merged
612 patch accepted. The general cycle for patch review and acceptance is:
614 #. Submit the patch.
622 git format-patch -3 -v 2
626 #. If the patch is deemed suitable for merging by the relevant maintainer(s) or other developers th…
627 the patch with an email that includes something like::
631 **Note**: When acking patches please remove as much of the text of the patch email as possible.
634 #. Having the patch ``Reviewed-by:`` and/or ``Tested-by:`` will also help the patch to be accepted.
636 #. If the patch isn't deemed suitable based on being out of scope or conflicting with existing func…
640 #. In addition a patch will not be accepted if it doesn't address comments from a previous version …
646 #. Once a patch has been acked by the relevant maintainer, reviewers may still comment on it for a …
647 …two weeks. After that time, the patch should be merged into the relevant git tree for the next rel…
654 * After the appropriate time for additional feedback has passed, if the patch has not yet
656 in that any additional changes needed to it must be addressed by a follow-on patch, rather