1.. _submitting-a-patch:
2
3Submitting a Patch
4==================
5
6QEMU welcomes contributions to fix bugs, add functionality or improve
7the documentation. However, we get a lot of patches, and so we have
8some guidelines about submitting them. If you follow these, you'll
9help make our task of contribution review easier and your change is
10likely to be accepted and committed faster.
11
12This page seems very long, so if you are only trying to post a quick
13one-shot fix, the bare minimum we ask is that:
14
15.. list-table:: Minimal Checklist for Patches
16   :widths: 35 65
17   :header-rows: 1
18
19   * - Check
20     - Reason
21   * - Patches contain Signed-off-by: Real Name <author@email>
22     - States you are legally able to contribute the code. See :ref:`patch_emails_must_include_a_signed_off_by_line`
23   * - Sent as patch emails to ``qemu-devel@nongnu.org``
24     - The project uses an email list based workflow. See :ref:`submitting_your_patches`
25   * - Be prepared to respond to review comments
26     - Code that doesn't pass review will not get merged. See :ref:`participating_in_code_review`
27
28You do not have to subscribe to post (list policy is to reply-to-all to
29preserve CCs and keep non-subscribers in the loop on the threads they
30start), although you may find it easier as a subscriber to pick up good
31ideas from other posts. If you do subscribe, be prepared for a high
32volume of email, often over one thousand messages in a week. The list is
33moderated; first-time posts from an email address (whether or not you
34subscribed) may be subject to some delay while waiting for a moderator
35to allow your address.
36
37The larger your contribution is, or if you plan on becoming a long-term
38contributor, then the more important the rest of this page becomes.
39Reading the table of contents below should already give you an idea of
40the basic requirements. Use the table of contents as a reference, and
41read the parts that you have doubts about.
42
43.. contents:: Table of Contents
44
45.. _writing_your_patches:
46
47Writing your Patches
48--------------------
49
50.. _use_the_qemu_coding_style:
51
52Use the QEMU coding style
53~~~~~~~~~~~~~~~~~~~~~~~~~
54
55You can run run *scripts/checkpatch.pl <patchfile>* before submitting to
56check that you are in compliance with our coding standards. Be aware
57that ``checkpatch.pl`` is not infallible, though, especially where C
58preprocessor macros are involved; use some common sense too. See also:
59
60-  :ref:`coding-style`
61-  `Automate a checkpatch run on
62   commit <https://blog.vmsplice.net/2011/03/how-to-automatically-run-checkpatchpl.html>`__
63
64.. _base_patches_against_current_git_master:
65
66Base patches against current git master
67~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
68
69There's no point submitting a patch which is based on a released version
70of QEMU because development will have moved on from then and it probably
71won't even apply to master. We only apply selected bugfixes to release
72branches and then only as backports once the code has gone into master.
73
74It is also okay to base patches on top of other on-going work that is
75not yet part of the git master branch. To aid continuous integration
76tools, such as `patchew <http://patchew.org/QEMU/>`__, you should `add a
77tag <https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg01288.html>`__
78line ``Based-on: $MESSAGE_ID`` to your cover letter to make the series
79dependency obvious.
80
81.. _split_up_long_patches:
82
83Split up long patches
84~~~~~~~~~~~~~~~~~~~~~
85
86Split up longer patches into a patch series of logical code changes.
87Each change should compile and execute successfully. For instance, don't
88add a file to the makefile in patch one and then add the file itself in
89patch two. (This rule is here so that people can later use tools like
90`git bisect <http://git-scm.com/docs/git-bisect>`__ without hitting
91points in the commit history where QEMU doesn't work for reasons
92unrelated to the bug they're chasing.) Put documentation first, not
93last, so that someone reading the series can do a clean-room evaluation
94of the documentation, then validate that the code matched the
95documentation. A commit message that mentions "Also, ..." is often a
96good candidate for splitting into multiple patches. For more thoughts on
97properly splitting patches and writing good commit messages, see `this
98advice from
99OpenStack <https://wiki.openstack.org/wiki/GitCommitMessages>`__.
100
101.. _make_code_motion_patches_easy_to_review:
102
103Make code motion patches easy to review
104~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
105
106If a series requires large blocks of code motion, there are tricks for
107making the refactoring easier to review. Split up the series so that
108semantic changes (or even function renames) are done in a separate patch
109from the raw code motion. Use a one-time setup of ``git config
110diff.renames true;`` ``git config diff.algorithm patience`` (refer to
111`git-config <http://git-scm.com/docs/git-config>`__). The 'diff.renames'
112property ensures file rename patches will be given in a more compact
113representation that focuses only on the differences across the file
114rename, instead of showing the entire old file as a deletion and the new
115file as an insertion. Meanwhile, the 'diff.algorithm' property ensures
116that extracting a non-contiguous subset of one file into a new file, but
117where all extracted parts occur in the same order both before and after
118the patch, will reduce churn in trying to treat unrelated ``}`` lines in
119the original file as separating hunks of changes.
120
121Ideally, a code motion patch can be reviewed by doing::
122
123    git format-patch --stdout -1 > patch;
124    diff -u <(sed -n 's/^-//p' patch) <(sed -n 's/^\+//p' patch)
125
126to focus on the few changes that weren't wholesale code motion.
127
128.. _dont_include_irrelevant_changes:
129
130Don't include irrelevant changes
131~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
132
133In particular, don't include formatting, coding style or whitespace
134changes to bits of code that would otherwise not be touched by the
135patch. (It's OK to fix coding style issues in the immediate area (few
136lines) of the lines you're changing.) If you think a section of code
137really does need a reindent or other large-scale style fix, submit this
138as a separate patch which makes no semantic changes; don't put it in the
139same patch as your bug fix.
140
141For smaller patches in less frequently changed areas of QEMU, consider
142using the :ref:`trivial-patches` process.
143
144.. _write_a_meaningful_commit_message:
145
146Write a meaningful commit message
147~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
148
149Commit messages should be meaningful and should stand on their own as a
150historical record of why the changes you applied were necessary or
151useful.
152
153QEMU follows the usual standard for git commit messages: the first line
154(which becomes the email subject line) is "subsystem: single line
155summary of change". Whether the "single line summary of change" starts
156with a capital is a matter of taste, but we prefer that the summary does
157not end in a dot. Look at ``git shortlog -30`` for an idea of sample
158subject lines. Then there is a blank line and a more detailed
159description of the patch, another blank and your Signed-off-by: line.
160Please do not use lines that are longer than 76 characters in your
161commit message (so that the text still shows up nicely with "git show"
162in a 80-columns terminal window).
163
164The body of the commit message is a good place to document why your
165change is important. Don't include comments like "This is a suggestion
166for fixing this bug" (they can go below the ``---`` line in the email so
167they don't go into the final commit message). Make sure the body of the
168commit message can be read in isolation even if the reader's mailer
169displays the subject line some distance apart (that is, a body that
170starts with "... so that" as a continuation of the subject line is
171harder to follow).
172
173If your patch fixes a commit that is already in the repository, please
174add an additional line with "Fixes: <at-least-12-digits-of-SHA-commit-id>
175("Fixed commit subject")" below the patch description / before your
176"Signed-off-by:" line in the commit message.
177
178If your patch fixes a bug in the gitlab bug tracker, please add a line
179with "Resolves: <URL-of-the-bug>" to the commit message, too. Gitlab can
180close bugs automatically once commits with the "Resolves:" keyword get
181merged into the master branch of the project. And if your patch addresses
182a bug in another public bug tracker, you can also use a line with
183"Buglink: <URL-of-the-bug>" for reference here, too.
184
185Example::
186
187 Fixes: 14055ce53c2d ("s390x/tcg: avoid overflows in time2tod/tod2time")
188 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/42
189 Buglink: https://bugs.launchpad.net/qemu/+bug/1804323``
190
191Some other tags that are used in commit messages include "Message-Id:"
192"Tested-by:", "Acked-by:", "Reported-by:", "Suggested-by:".  See ``git
193log`` for these keywords for example usage.
194
195.. _test_your_patches:
196
197Test your patches
198~~~~~~~~~~~~~~~~~
199
200Although QEMU uses various :ref:`ci` services that attempt to test
201patches submitted to the list, it still saves everyone time if you
202have already tested that your patch compiles and works. Because QEMU
203is such a large project the default configuration won't create a
204testing pipeline on GitLab when a branch is pushed. See the :ref:`CI
205variable documentation<ci_var>` for details on how to control the
206running of tests; but it is still wise to also check that your patches
207work with a full build before submitting a series, especially if your
208changes might have an unintended effect on other areas of the code you
209don't normally experiment with. See :ref:`testing` for more details on
210what tests are available.
211
212Also, it is a wise idea to include a testsuite addition as part of
213your patches - either to ensure that future changes won't regress your
214new feature, or to add a test which exposes the bug that the rest of
215your series fixes. Keeping separate commits for the test and the fix
216allows reviewers to rebase the test to occur first to prove it catches
217the problem, then again to place it last in the series so that
218bisection doesn't land on a known-broken state.
219
220.. _submitting_your_patches:
221
222Submitting your Patches
223-----------------------
224
225The QEMU project uses a public email based workflow for reviewing and
226merging patches. As a result all contributions to QEMU must be **sent
227as patches** to the qemu-devel `mailing list
228<https://wiki.qemu.org/Contribute/MailingLists>`__. Patch
229contributions should not be posted on the bug tracker, posted on
230forums, or externally hosted and linked to. (We have other mailing
231lists too, but all patches must go to qemu-devel, possibly with a Cc:
232to another list.) ``git send-email`` (`step-by-step setup guide
233<https://git-send-email.io/>`__ and `hints and tips
234<https://elixir.bootlin.com/linux/latest/source/Documentation/process/email-clients.rst>`__)
235works best for delivering the patch without mangling it, but
236attachments can be used as a last resort on a first-time submission.
237
238.. _if_you_cannot_send_patch_emails:
239
240If you cannot send patch emails
241~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
242
243In rare cases it may not be possible to send properly formatted patch
244emails. You can use `sourcehut <https://sourcehut.org/>`__ to send your
245patches to the QEMU mailing list by following these steps:
246
247#. Register or sign in to your account
248#. Add your SSH public key in `meta \|
249   keys <https://meta.sr.ht/keys>`__.
250#. Publish your git branch using **git push git@git.sr.ht:~USERNAME/qemu
251   HEAD**
252#. Send your patches to the QEMU mailing list using the web-based
253   ``git-send-email`` UI at https://git.sr.ht/~USERNAME/qemu/send-email
254
255`This video
256<https://spacepub.space/videos/watch/ad258d23-0ac6-488c-83fc-2bacf578de3a>`__
257shows the web-based ``git-send-email`` workflow. Documentation is
258available `here
259<https://man.sr.ht/git.sr.ht/#sending-patches-upstream>`__.
260
261.. _cc_the_relevant_maintainer:
262
263CC the relevant maintainer
264~~~~~~~~~~~~~~~~~~~~~~~~~~
265
266Send patches both to the mailing list and CC the maintainer(s) of the
267files you are modifying. look in the MAINTAINERS file to find out who
268that is. Also try using scripts/get_maintainer.pl from the repository
269for learning the most common committers for the files you touched.
270
271Example::
272
273    ~/src/qemu/scripts/get_maintainer.pl -f hw/ide/core.c
274
275In fact, you can automate this, via a one-time setup of ``git config
276sendemail.cccmd 'scripts/get_maintainer.pl --nogit-fallback'`` (Refer to
277`git-config <http://git-scm.com/docs/git-config>`__.)
278
279.. _do_not_send_as_an_attachment:
280
281Do not send as an attachment
282~~~~~~~~~~~~~~~~~~~~~~~~~~~~
283
284Send patches inline so they are easy to reply to with review comments.
285Do not put patches in attachments.
286
287.. _use_git_format_patch:
288
289Use ``git format-patch``
290~~~~~~~~~~~~~~~~~~~~~~~~
291
292Use the right diff format.
293`git format-patch <http://git-scm.com/docs/git-format-patch>`__ will
294produce patch emails in the right format (check the documentation to
295find out how to drive it). You can then edit the cover letter before
296using ``git send-email`` to mail the files to the mailing list. (We
297recommend `git send-email <http://git-scm.com/docs/git-send-email>`__
298because mail clients often mangle patches by wrapping long lines or
299messing up whitespace. Some distributions do not include send-email in a
300default install of git; you may need to download additional packages,
301such as 'git-email' on Fedora-based systems.) Patch series need a cover
302letter, with shallow threading (all patches in the series are
303in-reply-to the cover letter, but not to each other); single unrelated
304patches do not need a cover letter (but if you do send a cover letter,
305use ``--numbered`` so the cover and the patch have distinct subject lines).
306Patches are easier to find if they start a new top-level thread, rather
307than being buried in-reply-to another existing thread.
308
309.. _avoid_posting_large_binary_blob:
310
311Avoid posting large binary blob
312~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
313
314If you added binaries to the repository, consider producing the patch
315emails using ``git format-patch --no-binary`` and include a link to a
316git repository to fetch the original commit.
317
318.. _patch_emails_must_include_a_signed_off_by_line:
319
320Patch emails must include a ``Signed-off-by:`` line
321~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
322
323Your patches **must** include a Signed-off-by: line. This is a hard
324requirement because it's how you say "I'm legally okay to contribute
325this and happy for it to go into QEMU". The process is modelled after
326the `Linux kernel
327<http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n297>`__
328policy.
329
330If you wrote the patch, make sure your "From:" and "Signed-off-by:"
331lines use the same spelling. It's okay if you subscribe or contribute to
332the list via more than one address, but using multiple addresses in one
333commit just confuses things. If someone else wrote the patch, git will
334include a "From:" line in the body of the email (different from your
335envelope From:) that will give credit to the correct author; but again,
336that author's Signed-off-by: line is mandatory, with the same spelling.
337
338There are various tooling options for automatically adding these tags
339include using ``git commit -s`` or ``git format-patch -s``. For more
340information see `SubmittingPatches 1.12
341<http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n297>`__.
342
343.. _include_a_meaningful_cover_letter:
344
345Include a meaningful cover letter
346~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
347
348This is a requirement for any series with multiple patches (as it aids
349continuous integration), but optional for an isolated patch. The cover
350letter explains the overall goal of such a series, and also provides a
351convenient 0/N email for others to reply to the series as a whole. A
352one-time setup of ``git config format.coverletter auto`` (refer to
353`git-config <http://git-scm.com/docs/git-config>`__) will generate the
354cover letter as needed.
355
356When reviewers don't know your goal at the start of their review, they
357may object to early changes that don't make sense until the end of the
358series, because they do not have enough context yet at that point of
359their review. A series where the goal is unclear also risks a higher
360number of review-fix cycles because the reviewers haven't bought into
361the idea yet. If the cover letter can explain these points to the
362reviewer, the process will be smoother patches will get merged faster.
363Make sure your cover letter includes a diffstat of changes made over the
364entire series; potential reviewers know what files they are interested
365in, and they need an easy way determine if your series touches them.
366
367.. _use_the_rfc_tag_if_needed:
368
369Use the RFC tag if needed
370~~~~~~~~~~~~~~~~~~~~~~~~~
371
372For example, "[PATCH RFC v2]". ``git format-patch --subject-prefix=RFC``
373can help.
374
375"RFC" means "Request For Comments" and is a statement that you don't
376intend for your patchset to be applied to master, but would like some
377review on it anyway. Reasons for doing this include:
378
379-  the patch depends on some pending kernel changes which haven't yet
380   been accepted, so the QEMU patch series is blocked until that
381   dependency has been dealt with, but is worth reviewing anyway
382-  the patch set is not finished yet (perhaps it doesn't cover all use
383   cases or work with all targets) but you want early review of a major
384   API change or design structure before continuing
385
386In general, since it's asking other people to do review work on a
387patchset that the submitter themselves is saying shouldn't be applied,
388it's best to:
389
390-  use it sparingly
391-  in the cover letter, be clear about why a patch is an RFC, what areas
392   of the patchset you're looking for review on, and why reviewers
393   should care
394
395.. _consider_whether_your_patch_is_applicable_for_stable:
396
397Consider whether your patch is applicable for stable
398~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
399
400If your patch fixes a severe issue or a regression, it may be applicable
401for stable. In that case, consider adding ``Cc: qemu-stable@nongnu.org``
402to your patch to notify the stable maintainers.
403
404For more details on how QEMU's stable process works, refer to the
405:ref:`stable-process` page.
406
407.. _participating_in_code_review:
408
409Participating in Code Review
410----------------------------
411
412All patches submitted to the QEMU project go through a code review
413process before they are accepted. This will often mean a series will
414go through a number of iterations before being picked up by
415:ref:`maintainers<maintainers>`. You therefore should be prepared to
416read replies to your messages and be willing to act on them.
417
418Maintainers are often willing to manually fix up first-time
419contributions, since there is a learning curve involved in making an
420ideal patch submission. However for the best results you should
421proactively respond to suggestions with changes or justifications for
422your current approach.
423
424Some areas of code that are well maintained may review patches
425quickly, lesser-loved areas of code may have a longer delay.
426
427.. _stay_around_to_fix_problems_raised_in_code_review:
428
429Stay around to fix problems raised in code review
430~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
431
432Not many patches get into QEMU straight away -- it is quite common that
433developers will identify bugs, or suggest a cleaner approach, or even
434just point out code style issues or commit message typos. You'll need to
435respond to these, and then send a second version of your patches with
436the issues fixed. This takes a little time and effort on your part, but
437if you don't do it then your changes will never get into QEMU.
438
439Remember that a maintainer is under no obligation to take your
440patches. If someone has spent the time reviewing your code and
441suggesting improvements and you simply re-post without either
442addressing the comment directly or providing additional justification
443for the change then it becomes wasted effort. You cannot demand others
444merge and then fix up your code after the fact.
445
446When replying to comments on your patches **reply to all and not just
447the sender** -- keeping discussion on the mailing list means everybody
448can follow it. Remember the spirit of the :ref:`code_of_conduct` and
449keep discussions respectful and collaborative and avoid making
450personal comments.
451
452.. _pay_attention_to_review_comments:
453
454Pay attention to review comments
455~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
456
457Someone took their time to review your work, and it pays to respect that
458effort; repeatedly submitting a series without addressing all comments
459from the previous round tends to alienate reviewers and stall your
460patch. Reviewers aren't always perfect, so it is okay if you want to
461argue that your code was correct in the first place instead of blindly
462doing everything the reviewer asked. On the other hand, if someone
463pointed out a potential issue during review, then even if your code
464turns out to be correct, it's probably a sign that you should improve
465your commit message and/or comments in the code explaining why the code
466is correct.
467
468If you fix issues that are raised during review **resend the entire
469patch series** not just the one patch that was changed. This allows
470maintainers to easily apply the fixed series without having to manually
471identify which patches are relevant. Send the new version as a complete
472fresh email or series of emails -- don't try to make it a followup to
473version 1. (This helps automatic patch email handling tools distinguish
474between v1 and v2 emails.)
475
476.. _when_resending_patches_add_a_version_tag:
477
478When resending patches add a version tag
479~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
480
481All patches beyond the first version should include a version tag -- for
482example, "[PATCH v2]". This means people can easily identify whether
483they're looking at the most recent version. (The first version of a
484patch need not say "v1", just [PATCH] is sufficient.) For patch series,
485the version applies to the whole series -- even if you only change one
486patch, you resend the entire series and mark it as "v2". Don't try to
487track versions of different patches in the series separately.  `git
488format-patch <http://git-scm.com/docs/git-format-patch>`__ and `git
489send-email <http://git-scm.com/docs/git-send-email>`__ both understand
490the ``-v2`` option to make this easier. Send each new revision as a new
491top-level thread, rather than burying it in-reply-to an earlier
492revision, as many reviewers are not looking inside deep threads for new
493patches.
494
495.. _include_version_history_in_patchset_revisions:
496
497Include version history in patchset revisions
498~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
499
500For later versions of patches, include a summary of changes from
501previous versions, but not in the commit message itself. In an email
502formatted as a git patch, the commit message is the part above the ``---``
503line, and this will go into the git changelog when the patch is
504committed. This part should be a self-contained description of what this
505version of the patch does, written to make sense to anybody who comes
506back to look at this commit in git in six months' time. The part below
507the ``---`` line and above the patch proper (git format-patch puts the
508diffstat here) is a good place to put remarks for people reading the
509patch email, and this is where the "changes since previous version"
510summary belongs. The `git-publish
511<https://github.com/stefanha/git-publish>`__ script can help with
512tracking a good summary across versions. Also, the `git-backport-diff
513<https://github.com/codyprime/git-scripts>`__ script can help focus
514reviewers on what changed between revisions.
515
516.. _tips_and_tricks:
517
518Tips and Tricks
519---------------
520
521.. _proper_use_of_reviewed_by_tags_can_aid_review:
522
523Proper use of Reviewed-by: tags can aid review
524~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
525
526When reviewing a large series, a reviewer can reply to some of the
527patches with a Reviewed-by tag, stating that they are happy with that
528patch in isolation (sometimes conditional on minor cleanup, like fixing
529whitespace, that doesn't affect code content). You should then update
530those commit messages by hand to include the Reviewed-by tag, so that in
531the next revision, reviewers can spot which patches were already clean
532from the previous round. Conversely, if you significantly modify a patch
533that was previously reviewed, remove the reviewed-by tag out of the
534commit message, as well as listing the changes from the previous
535version, to make it easier to focus a reviewer's attention to your
536changes.
537
538.. _if_your_patch_seems_to_have_been_ignored:
539
540If your patch seems to have been ignored
541~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
542
543If your patchset has received no replies you should "ping" it after a
544week or two, by sending an email as a reply-to-all to the patch mail,
545including the word "ping" and ideally also a link to the page for the
546patch on `patchew <https://patchew.org/QEMU/>`__ or
547`lore.kernel.org <https://lore.kernel.org/qemu-devel/>`__. It's worth
548double-checking for reasons why your patch might have been ignored
549(forgot to CC the maintainer? annoyed people by failing to respond to
550review comments on an earlier version?), but often for less-maintained
551areas of QEMU patches do just slip through the cracks. If your ping is
552also ignored, ping again after another week or so. As the submitter, you
553are the person with the most motivation to get your patch applied, so
554you have to be persistent.
555
556.. _is_my_patch_in:
557
558Is my patch in?
559~~~~~~~~~~~~~~~
560
561QEMU has some Continuous Integration machines that try to catch patch
562submission problems as soon as possible.  `patchew
563<http://patchew.org/QEMU/>`__ includes a web interface for tracking the
564status of various threads that have been posted to the list, and may
565send you an automated mail if it detected a problem with your patch.
566
567Once your patch has had enough review on list, the maintainer for that
568area of code will send notification to the list that they are including
569your patch in a particular staging branch. Periodically, the maintainer
570then takes care of :ref:`submitting-a-pull-request`
571for aggregating topic branches into mainline QEMU. Generally, you do not
572need to send a pull request unless you have contributed enough patches
573to become a maintainer over a particular section of code. Maintainers
574may further modify your commit, by resolving simple merge conflicts or
575fixing minor typos pointed out during review, but will always add a
576Signed-off-by line in addition to yours, indicating that it went through
577their tree. Occasionally, the maintainer's pull request may hit more
578difficult merge conflicts, where you may be requested to help rebase and
579resolve the problems. It may take a couple of weeks between when your
580patch first had a positive review to when it finally lands in qemu.git;
581release cycle freezes may extend that time even longer.
582
583.. _return_the_favor:
584
585Return the favor
586~~~~~~~~~~~~~~~~
587
588Peer review only works if everyone chips in a bit of review time. If
589everyone submitted more patches than they reviewed, we would have a
590patch backlog. A good goal is to try to review at least as many patches
591from others as what you submit. Don't worry if you don't know the code
592base as well as a maintainer; it's perfectly fine to admit when your
593review is weak because you are unfamiliar with the code.
594