Contribute/SubmitAPatch
QEMU welcomes contributions of code (either fixing bugs or adding new functionality). However, we get a lot of patches, and so we have some guidelines about submitting patches. If you follow these, you'll help make our task of code review easier and your patch is likely to be committed faster.
All contributions to QEMU must be sent as patches to the qemu-devel mailing list. Patch contributions should not be posted on the bug tracker, posted on forums, or externally hosted and linked to.
Send patches to the mailing list and CC the relevant maintainer -- look in the MAINTAINERS file to find out who that is.
Send patches inline so they are easy to reply to with review comments. Do not put patches in attachments.
Use the right patch format. git format-patch will produce patch emails in the right format (check the documentation to find out how to drive it). You can then edit the cover letter before using git send-email to mail the files to the mailing list. (We recommend git send-email because mail clients often mangle patches by wrapping long lines or messing up whitespace.) Patch series need a cover letter, with shallow threading (all patches in the series are in-reply-to the cover letter, but not to each other); single unrelated patches do not need a cover letter.
Patch emails must include a Signed-off-by: line. For more information see SubmittingPatches 1.12. This is vital or we will not be able to apply your patch! Please use your real name to sign a patch (not an alias name).
Make the cover letter meaningful. When reviewers don't know your goal at the start of their review, they may object to things that make sense at the end of the series because they do not have enough context yet. A series where the goal is unclear also risks a higher number of review-fix cycles because the reviewers haven't bought into the idea yet. It is in everyone's interest to explain the goal in the cover letter. Then the patches get reviewed more smoothly and merged faster.
Follow the coding style and run scripts/checkpatch.pl <patchfile> before submitting. (Be aware that checkpatch.pl is not infallible, though, especially where C preprocessor macros are involved; use some common sense too.) See also:
Correct English is appreciated. If you are not sure, codespell or other programs help finding the most common spelling mistakes in code and documentation.
Patches should be against current git master. There's no point submitting a patch which is based on a released version of QEMU because development will have moved on from then and it probably won't even apply to master. We only apply selected bugfixes to release branches and then only as backports once the code has gone into master.
Split up longer patches into a patch series of logical code changes. Each change should compile and execute successfully. For instance, don't add a file to the makefile in patch one and then add the file itself in patch two. (This rule is here so that people can later use tools like git bisect without hitting points in the commit history where QEMU doesn't work for reasons unrelated to the bug they're chasing.)
Don't include irrelevant changes. In particular, don't include formatting, coding style or whitespace changes to bits of code that would otherwise not be touched by the patch. (It's OK to fix coding style issues in the immediate area (few lines) of the lines you're changing.) If you think a section of code really does need a reindent or other large-scale style fix, submit this as a separate patch which makes no semantic changes; don't put it in the same patch as your bug fix.
For smaller patches in less frequently changed areas of QEMU, consider using the trivial patches process.
Write a good commit message. QEMU follows the usual standard for git commit messages: the first line (which becomes the email subject line) is "subsystem: single line summary of change". Then there is a blank line and a more detailed description of the patch, another blank and your Signed-off-by: line. Don't include comments like "This is a suggestion for fixing this bug" (they can go below the "---" line in the email so they don't go into the final commit message).
Stay around to fix problems raised in code review. Not many patches get into QEMU straight away -- it is quite common that developers will identify bugs, or suggest a cleaner approach, or even just point out code style issues or commit message typos. You'll need to respond to these, and then send a second version of your patches with the issues fixed. This takes a little time and effort on your part, but if you don't do it then your changes will never get into QEMU. It's also just polite -- it is quite disheartening for a developer to spend time reviewing your code and suggesting improvements, only to find that you're not going to do anything further and it was all wasted effort.
When replying to comments on your patches reply to all and not just the sender -- keeping discussion on the mailing list means everybody can follow it.
If you fix issues that are raised during review resend the entire patch series not just the one patch that was changed. This allows maintainers to easily apply the fixed series without having to manually identify which patches are relevant. Send the new version as a complete fresh email or series of emails -- don't try to make it a followup to version 1. (This helps automatic patch email handling tools distinguish between v1 and v2 emails.)
When resending patches add a v2/v3 suffix (eg [PATCH v2]). This means people can easily identify whether they're looking at the most recent version. (The first version of a patch need not say "v1", just [PATCH] is sufficient.) For patch series, the version applies to the whole series -- even if you only change one patch, you resend the entire series and mark it as "v2". Don't try to track versions of different patches in the series separately.
For later versions of patches include a summary of changes from previous versions, but not in the commit message itself. In an email formatted as a git patch, the commit message is the part above the "---" line, and this will go into the git changelog when the patch is committed. This part should be a self-contained description of what this version of the patch does, written to make sense to anybody who comes back to look at this commit in git in six months' time. The part below the "---" line and above the patch proper (git format-patch puts the diffstat here) is a good place to put remarks for people reading the patch email, and this is where the "changes since previous version" summary belongs.
If your patch seems to have been ignored you should "ping" it after a week or two, by sending an email as a reply-to-all to the patch mail, including the word "ping" and ideally also a link to the page for the patch on patchwork or GMANE. It's worth double-checking for reasons why your patch might have been ignored (forgot to CC the maintainer? annoyed people by failing to respond to review comments on an earlier version?), but often for less-maintained areas of QEMU patches do just slip through the cracks. If your ping is also ignored, ping again after another week or so. As the submitter, you are the person with the most motivation to get your patch applied, so you have to be persistent.