Contribute/SubmitAPatch: Difference between revisions
(Add some suggestions for patch resends) |
No edit summary |
||
| Line 15: | Line 15: | ||
'''Split up longer patches''' into a patch series of logical code changes. Each change should compile and execute successfully. | '''Split up longer patches''' into a patch series of logical code changes. Each change should compile and execute successfully. | ||
For smaller patches in less frequently changed areas of QEMU, consider using the [[Contribute/TrivialPatches|trivial patches]] process. | For smaller patches in less frequently changed areas of QEMU, '''consider using the [[Contribute/TrivialPatches|trivial patches]] process'''. | ||
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. | 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. | ||
'''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.) | '''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 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. | |||
Revision as of 15:49, 11 November 2011
All contributions to QEMU are 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.
You get a better chance to get a reply if you follow the LKML rule of send directly to the maintainer of the portion of the patch (see MAINTAINERS file). Also keep attention to reply to all and not just the sender.
Consider also to prefix your patch commit messages with the portion you changed (ie: block or tcg).
Send patches inline so they are easy to reply to with review comments. Do not put patches in attachments.
Patch emails must include a Signed-off-by: line. For more information see SubmittingPatches 1.12.
Follow the coding style and run scripts/checkpatch.pl <patchfile> before submitting. See also:
Split up longer patches into a patch series of logical code changes. Each change should compile and execute successfully.
For smaller patches in less frequently changed areas of QEMU, consider using the trivial patches process.
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.
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 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.