|
|
| (15 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| '''NB: this page is a draft work in progress and may not yet reflect consensus on the rules for pull requests.'''
| | Moved at https://www.qemu.org/docs/master/devel/submitting-a-pull-request.html |
| | |
| QEMU welcomes contributions of code, but we generally expect these to be
| |
| sent as simple patch emails to the mailing list (see our
| |
| page on [[Contribute/SubmitAPatch|submitting a patch]] for more details).
| |
| Generally only existing submaintainers of a tree will need to
| |
| submit pull requests, although occasionally for a large patch
| |
| series we might ask a submitter to send a pull request. This
| |
| page documents our recommendations on pull requests for those people.
| |
| | |
| | |
| '''Retransmit the patches in the pull request''' as emails which are
| |
| threaded as follow-ups to the pull request itself. The simplest
| |
| way to do this is to use <code>git format-patch --cover-letter</code>
| |
| to create the emails, and then edit the cover letter to include
| |
| the pull request details that <code>git request-pull</code> outputs.
| |
| | |
| '''Use PULL as the subject line tag''' in both the cover letter
| |
| and the retransmitted patch mails (for example, by using
| |
| <code>--subject-prefix=PULL</code> in your <code>git format-patch</code>
| |
| command). This helps people to filter in or out the resulting emails
| |
| (especially useful if they are only CC'd on one email out of the set).
| |
| | |
| '''Each patch must have your own Signed-off-by: line''' as well as
| |
| that of the original author if the patch was not written by you.
| |
| This is because with a pull request you're now indicating that the
| |
| patch has passed via you rather than directly from the original author.
| |
| | |
| '''Don't send pull requests for code that hasn't passed review'''.
| |
| A pull request says these patches are ready to go into QEMU now,
| |
| so they must have passed the standard code review processes.
| |
| In particular if you've corrected issues in one round of code review,
| |
| you need to send your fixed patch series as normal to the list;
| |
| you can't put it in a pull request until it's gone through.
| |
| (Extremely trivial fixes are be OK to just fix in passing, but
| |
| if in doubt err on the side of not.)
| |
| | |
| '''Test before sending'''. This is an obvious thing to say, but
| |
| make sure everything builds and that "make check" passes before
| |
| sending out the pull request.
| |
