Lines Matching refs:patch

6 Certifying patch submissions
10 patch submissions they make to the project. To put it another way,
19 The addition of this line asserts that the author of the patch is contributing
62 If the person sending the mail is not one of the patch authors, they are
69 It is not uncommon for a patch to have contributions from multiple authors. In
71 line for each contributor involved in creation of the patch. Some edge cases:
78     of code as suggested fixes to a patch. The reviewers don't need to have
102  * **``Reviewed-by``**: when a QEMU community member reviews a patch on the
103    mailing list, if they consider the patch acceptable, they should send an
105    review a patch should add this even if they are also adding their
108  * **``Acked-by``**: when a QEMU subsystem maintainer approves a patch that
111    ``Acked-by`` tag. Where a patch touches multiple subsystems, ``Acked-by``
117    behaviour of the patch in some manner, they should send an email reply
123    any patch fixing the issue. When the problem is reported via the GitLab
128    suggestions for how to change a patch, it is good practice to credit them
134 When a subsystem maintainer accepts a patch from a contributor, in addition to
138 At the time they queue the patch in their subsystem tree, the maintainer
143 When the maintainer modifies the patch after pulling into their tree, they
165 If preparing patches using the ``git format-patch`` tool, the ``-s`` flag can
207 continue working from the abandoned patch and re-submit it with extra changes.
213  * Indicate where the original patch was obtained from (mailing list, bug
216    ``Signed-off-by`` in the patch in addition to the orignal author's
217  * Indicate who is responsible for what parts of the patch. This is typically
281 boilerplate code template which is then filled in to produce the final patch.
302 The QEMU community requires that contributors certify their patch submissions
306 To satisfy the DCO, the patch contributor has to fully understand the