docs/devel/submitting-a-patch.rst

23    * - Sent as patch emails to ``qemu-devel@nongnu.org``
30 start), although you may find it easier as a subscriber to pick up good
40 the basic requirements. Use the table of contents as a reference, and
72 branches and then only as backports once the code has gone into master.
76 tools, such as `patchew <http://patchew.org/QEMU/>`__, you should `add a
114 rename, instead of showing the entire old file as a deletion and the new
115 file as an insertion. Meanwhile, the 'diff.algorithm' property ensures
119 the original file as separating hunks of changes.
138 as a separate patch which makes no semantic changes; don't put it in the
139 same patch as your bug fix.
149 Commit messages should be meaningful and should stand on their own as a
170 starts with "... so that" as a continuation of the subject line is
212 Also, it is a wise idea to include a testsuite addition as part of
226 merging patches. As a result all contributions to QEMU must be **sent
227 as patches** to the qemu-devel `mailing list
236 attachments can be used as a last resort on a first-time submission.
258 'scripts/get_maintainers.pl' and automatically CC anyone listed as maintainers
303 Do not send as an attachment
323 such as 'git-email' on Fedora-based systems.) Patch series need a cover
356 This is a requirement for any series with multiple patches (as it aids
359 convenient 0/N email for others to reply to the series as a whole. A
362 cover letter as needed.
493 identify which patches are relevant. Send the new version as a complete
508 patch, you resend the entire series and mark it as "v2". Don't try to
512 the ``-v2`` option to make this easier. Send each new revision as a new
514 revision, as many reviewers are not looking inside deep threads for new
524 formatted as a git patch, the commit message is the part above the ``---``
556 commit message, as well as listing the changes from the previous
566 week or two, by sending an email as a reply-to-all to the patch mail,
574 also ignored, ping again after another week or so. As the submitter, you
584 submission problems as soon as possible.  `patchew
612 patch backlog. A good goal is to try to review at least as many patches
613 from others as what you submit. Don't worry if you don't know the code
614 base as well as a maintainer; it's perfectly fine to admit when your