@@ -10,10 +10,31 @@ Before a change is committed, you must make sure it is ready to enter the
10
10
public source tree. Draft commits are prohibited. Therefore, you must
11
11
ensure your changes fulfill several mandatory criteria.
12
12
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):
16
+
17
+ #. Has the submitter signed the CLA?
18
+ (delineated by a label on the pull request)
19
+ #. Did the test suite pass? (delineated by a pull request check)
20
+ #. Did code coverage increase or stay the same?
21
+ (delineated by a comment on the pull request)
22
+ #. Are the changes acceptable?
23
+ #. Was ``configure `` regenerated (if necessary)?
24
+ #. Was ``pyconfig.h.in `` regenerated (if necessary)?
25
+ #. Was the submitter added to ``Misc/ACKS `` (as appropriate)?
26
+ #. Was ``Misc/NEWS `` updated (as appropriate)?
27
+ #. Was "What's New" updated
28
+ (or the pull request labeled as needing a "What's New" entry)?
29
+ #. Were appropriate labels added to signify necessary backporting of the
30
+ pull request?
31
+
13
32
.. note ::
14
33
If you want to share your work-in-progress code on a feature or bugfix,
15
- either open a WIP-prefixed PR, publish patches on the `issue tracker `_ or
16
- create a public fork of the repository.
34
+ either open a ``WIP ``-prefixed PR, publish patches on the
35
+ `issue tracker `_ or create a public fork of the repository.
36
+
37
+ .. _issue tracker : https://bugs.python.org
17
38
18
39
19
40
Does the test suite still pass?
@@ -83,7 +104,7 @@ more. In particular:
83
104
feature/bugfix.
84
105
85
106
It is of course okay to pile up several commits to one branch and merge them
86
- into another in one merge commit.
107
+ into another in one commit.
87
108
88
109
89
110
Handling Others' Code
@@ -96,7 +117,7 @@ First, make sure the patch is in a good state. Both :ref:`patch` and
96
117
:ref: `helptriage `
97
118
explain what is to be expected of a patch. Typically patches that get cleared by
98
119
triagers are good to go except maybe lacking ``Misc/ACKS `` and ``Misc/NEWS ``
99
- entries.
120
+ entries (which a core developer should make sure are updated appropriately) .
100
121
101
122
Second, make sure the patch does not break backwards-compatibility without a
102
123
good reason. This means :ref: `running the entire test suite <runtests >` to
@@ -105,8 +126,8 @@ there must be a good reason for the breakage of code the change will cause
105
126
(and it **will ** break someone's code). If you are unsure if the breakage
106
127
is worth it, ask on python-dev.
107
128
108
- Third, ensure the patch is attributed correctly by adding the contributor's
109
- name to ``Misc/ACKS `` if they aren't already there (and didn't add themselves
129
+ Third, ensure the patch is attributed correctly with the contributor's
130
+ name in ``Misc/ACKS `` if they aren't already there (and didn't add themselves
110
131
in their patch) and by mentioning "Patch by <x>" in the ``Misc/NEWS `` entry
111
132
and the checkin message. If the patch has been heavily modified then "Initial
112
133
patch by <x>" is an appropriate alternate wording.
@@ -115,10 +136,11 @@ If you omit correct attribution in the initial checkin, then update ``ACKS``
115
136
and ``NEWS `` in a subsequent checkin (don't worry about trying to fix the
116
137
original checkin message in that case).
117
138
118
- Finally, especially for larger patches, check if the submitter of the
139
+ Finally, make sure that the submitter of the
119
140
patch has a CLA in place (indicated by an asterisk following their username
120
- in the `issue tracker `_). If the asterisk is missing and the patch is
121
- non-trivial, direct them to the electronic `Contributor Licensing Agreement `_
141
+ in the `issue tracker `_ or by the "CLA Signed" label on the pull request).
142
+ If the submitter lacks a signed CLA and the patch is non-trivial, direct them
143
+ to the electronic `Contributor Licensing Agreement `_
122
144
to ensure the PSF has the appropriate authorizations in place to relicense
123
145
and redistribute their code.
124
146
@@ -196,7 +218,7 @@ be used to refer to objects in the documentation. Example NEWS entry::
196
218
(In all other ``.rst `` files, the single backticks should not be used. They are
197
219
allowed here because NEWS is meant to be as readable as possible unprocessed.)
198
220
199
- A nice trick to make Mercurial’s automatic file merge work more smoothly is to
221
+ A nice trick to make merging across branches work more smoothly is to
200
222
put a new entry after the first or first two entries rather than at the very
201
223
top. This way if you commit, pull new changesets and merge, the merge will
202
224
succeed automatically.
@@ -215,8 +237,10 @@ it is common to simply paste the NEWS entry into the commit message. Here
215
237
is an example::
216
238
217
239
Issue #42: the spam module is now more spammy.
240
+
218
241
The spam module sporadically came up short on spam. This change
219
242
raises the amount of spam in the module by making it more spammy.
243
+
220
244
Thanks to Monty Python for the patch.
221
245
222
246
The first line or sentence is meant to be a dense, to-the-point explanation
@@ -226,30 +250,6 @@ a new paragraph(s) can be added to explain in proper depth what has happened
226
250
understands the justification for the change). Also, if a non-core developer
227
251
contributed to the resolution, it is good practice to credit them.
228
252
229
- Hooks
230
- '''''''''''''''
231
-
232
- Special hooks have been added to the repository to enable notifying the `issue tracker `_
233
- of a commit related to an issue.
234
-
235
- A commit message can mention one or several issues in one of the following
236
- ways::
237
-
238
- #12345
239
- issue12345
240
- issue 12345
241
- bug12345
242
- bug 12345
243
-
244
- where 12345 is the number of the issue. The commit details (including its
245
- changeset, branch and commit message) will then be posted as a message to the
246
- issue's page in the tracker, for each mentioned issue.
247
-
248
- If "closes" (or "closed", or "closing") is prepended, the issue is
249
- automatically closed as "fixed".
250
-
251
- .. _issue tracker : https://bugs.python.org
252
-
253
253
254
254
Working with Git _
255
255
=======================
0 commit comments