|
1 | 1 | .. _committing:
|
2 | 2 |
|
3 |
| -Committing and Pushing Changes |
4 |
| -============================== |
| 3 | +Accepting Pull Requests |
| 4 | +======================= |
5 | 5 |
|
6 |
| -Is the change ready for committing? |
7 |
| ------------------------------------ |
| 6 | +This page is aimed to core developers, and covers the steps required to |
| 7 | +accept, merge, and possibly backport a pull request on the main repository. |
8 | 8 |
|
9 |
| -Before a change is committed, you must make sure it is ready to enter the |
10 |
| -public source tree. Draft commits are prohibited. Therefore, you must |
11 |
| -ensure your changes fulfill several mandatory criteria. |
| 9 | +Is the PR ready to be accepted? |
| 10 | +------------------------------- |
12 | 11 |
|
13 |
| -When working a pull request on GitHub, use the following as a checklist of |
14 |
| -what to check for before merging (details of various steps can be found |
15 |
| -later in this document): |
| 12 | +Before a PR is accepted, you must make sure it is ready to enter the public |
| 13 | +source tree. Use the following as a checklist of what to check for before |
| 14 | +merging (details of various steps can be found later in this document): |
16 | 15 |
|
17 | 16 | #. Has the submitter signed the CLA?
|
18 | 17 | (delineated by a label on the pull request)
|
@@ -40,14 +39,14 @@ Does the test suite still pass?
|
40 | 39 | '''''''''''''''''''''''''''''''
|
41 | 40 |
|
42 | 41 | You must :ref:`run the whole test suite <runtests>` to ensure that it
|
43 |
| -passes before pushing any code changes. |
| 42 | +passes before merging any code changes. |
44 | 43 |
|
45 | 44 | .. note::
|
46 | 45 | You really need to run the **entire** test suite. Running a single test
|
47 |
| - is not enough as your changes may have unforeseen effects on other tests |
| 46 | + is not enough as the changes may have unforeseen effects on other tests |
48 | 47 | or library modules.
|
49 | 48 |
|
50 |
| - Running the entire test suite doesn't guarantee that your changes |
| 49 | + Running the entire test suite doesn't guarantee that the changes |
51 | 50 | will pass the :ref:`continuous integration <buildbots>` tests, as those
|
52 | 51 | will exercise more possibilities still (such as different platforms or
|
53 | 52 | build options). But it will at least catch non-build specific,
|
@@ -93,6 +92,8 @@ making a complete patch.
|
93 | 92 | Commit Style
|
94 | 93 | ------------
|
95 | 94 |
|
| 95 | +.. move this to pullrequest |
| 96 | +
|
96 | 97 | Once a change patch is ready and tested, it can be committed to the repository.
|
97 | 98 | We usually prefer to put a whole feature or bugfix into a single commit, but no
|
98 | 99 | more. In particular:
|
@@ -240,6 +241,8 @@ unprocessed.)
|
240 | 241 | Commit Messages
|
241 | 242 | ---------------
|
242 | 243 |
|
| 244 | +.. move to pullrequest |
| 245 | +
|
243 | 246 | Every commit has a commit message to document why a change was made and to
|
244 | 247 | communicate that reason to other core developers. Python core developers have
|
245 | 248 | developed a standard way of formatting commit messages that everyone is
|
|
0 commit comments