docs/devel/submitting-a-pull-request.rst

1 .. _submitting-a-pull-request:
3 Submitting a Pull Request
10 will need to submit pull requests, although occasionally for a large
11 patch series we might ask a submitter to send a pull request. This page
12 documents our recommendations on pull requests for those people.
14 A good rule of thumb is not to send a pull request unless somebody asks
17 **Resend the patches with the pull request** as emails which are
18 threaded as follow-ups to the pull request itself. The simplest way to
20 emails, and then edit the cover letter to include the pull request
21 details that ``git request-pull`` outputs.
23 **Use PULL as the subject line tag** in both the cover letter and the
25 ``--subject-prefix=PULL`` in your ``git format-patch`` command). This
31 with a pull request you're now indicating that the patch has passed via
35 people have reviewed the patches you're putting in the pull request,
42 **Don't send pull requests for code that hasn't passed review**. A pull
46 fixed patch series as normal to the list; you can't put it in a pull
52 series) and that "make check" passes before sending out the pull
56 **All pull requests must be signed**. By "signed" here we mean that
61 **Pull requests not for master should say "not for master" and have
62 "PULL SUBSYSTEM whatever" in the subject tag**. If your pull request is
65 subject tag is "PULL SUBSYSTEM s390/block/whatever" rather than just
66 "PULL". This allows it to be automatically filtered out of the set of
67 pull requests that should be applied to master.