| Oct | NOV | Dec |
| 25 | ||
| 2019 | 2020 | 2021 |
COLLECTED BY
Collection: Common Crawl
●Python »
Python Developer's Guide »
configure regenerated (if necessary)?
(六)Was pyconfig.h.in regenerated (if necessary)?
(七)Was the submitter added to Misc/ACKS (as appropriate)?
(八)Was an entry added under Misc/NEWS.d/next (as appropriate)?
(九)Was “What’s New” updated (as appropriate)?
(十)Were appropriate labels added to signify necessary backporting of the
pull request?
(11)Was the pull request first made against the master branch?
Note
If you want to share your work-in-progress code on a feature or bugfix,
either open a WIP-prefixed PR, publish patches on the
issue tracker or create a public fork of the repository.
Misc/ACKS and Misc/NEWS.d
entries (which a core developer should make sure are updated appropriately).
Second, make sure the patch does not break backwards-compatibility without a
good reason. This means running the entire test suite to
make sure everything still passes. It also means that if semantics do change
there must be a good reason for the breakage of code the change will cause
(and it will break someone’s code). If you are unsure if the breakage
is worth it, ask on python-dev.
Third, ensure the patch is attributed correctly with the contributor’s
name in Misc/ACKS if they aren’t already there (and didn’t add themselves
in their patch) and by mentioning “Patch by <x>” in the Misc/NEWS.d entry
and the check-in message. If the patch has been heavily modified then “Initial
patch by <x>” is an appropriate alternate wording. GitHub now supports multiple
authors
in a commit. Add Co-authored-by: name <name@example.com> at the end of the commit message.
If you omit correct attribution in the initial check-in, then update ACKS
and NEWS.d in a subsequent check-in (don’t worry about trying to fix the
original check-in message in that case).
Finally, make sure that the submitter of the
patch has a CLA in place (indicated by an asterisk following their username
in the issue tracker or by the “CLA Signed” label on the pull request).
If the submitter lacks a signed CLA and the patch is non-trivial, direct them
to the electronic Contributor Licensing Agreement
to ensure the PSF has the appropriate authorizations in place to relicense
and redistribute their code.
https://check-python-cla.herokuapp.com/and put in their GitHub username. For further questions about the CLA process, write to: contributors@python.org.
Misc/NEWS.d.
If the change is particularly interesting for end users (e.g. new features,
significant improvements, or backwards-incompatible changes), an entry in
the What's New inPython document (inDoc/whatsnew/) should be added
as well. Changes that affect documentation only generally do not require
a news entry.
There are two notable exceptions to this general principle, and they
both relate to changes that already have a news entry, and have not yet
been included in any formal release (including alpha and beta releases).
These exceptions are:
●If a change is reverted prior to release, then the corresponding entry
is simply removed. Otherwise, a new entry must be added noting that the
change has been reverted (e.g. when a feature is released in an alpha and
then cut prior to the first beta).
●If a change is a fix (or other adjustment) to an earlier unreleased change
and the original news entry remains valid, then no additional entry is
needed.
Needing a What’s New entry almost always means that a change is not
suitable for inclusion in a maintenance release. A small number of
exceptions have been made for Python 2.7 due to the long support period -
when implemented, these changes must be noted in the “New Additions in
Python 2.7 Maintenance Releases” section of the Python 2.7 What’s New
document.
News entries go into the Misc/NEWS.d directory as individual files. The
news entry can be created by using blurb-it,
or the blurb tool and its blurb add
command.
If you are unable to use the tool you can create the news entry file manually.
The Misc/NEWS.d directory contains a sub-directory named next which
itself contains various sub-directories representing classifications for what
was affected (e.g. Misc/NEWS.d/next/Library for changes relating to the
standard library). The file name itself should be of the format
<datetime>.bpo-<issue-number>.<nonce>.rst:
●<datetime> is today’s date joined with a - to the current
time, in YYYY-MM-DD-hh-mm-ss format, e.g. 2017-05-27-16-46-23
●<issue-number> is the issue number the change is for, e.g. 12345
for bpo-12345
●<nonce> is some “unique” string to guarantee the file name is
unique across branches, e.g. Yl4gI2 (typically six characters, but it can
be any length of letters and numbers, and its uniqueness can be satisfied by
typing random characters on your keyboard)
So a file name may be
Misc/NEWS.d/next/Library/2017-05-27-16-46-23.bpo-12345.Yl4gI2.rst.
The contents of a news file should be valid reStructuredText. An 80 character
column width should be used. There is no indentation or leading marker in the
file (e.g. -). There is also no need to start the entry with the issue
number as it’s part of the file name itself. You can use
inline markups too. Example news entry:
Fix warning message when :func:`os.chdir` fails inside :func:`test.support.temp_cwd`. Patch by Chris Jerdonek.The inline Sphinx roles like
:func: can be used to assist readers in finding
more information. You can build html and verify that the link target is
appropriate by using make html.
While Sphinx roles can be beneficial to readers, they are not required.
Inline ``code blocks`` can be used instead.
master branch, or any of the
maintenance branches (currently 3.9 and 3.8).
You should commit against your own feature branch, and create a pull request.
●For a small change, you can make a quick edit through the GitHub web UI.
If you choose to use the web UI, be aware that GitHub will
create a new branch in the main CPython repo (not your fork). Please
delete this newly created branch after it has been merged into the
master branch or any of the maintenance branches. To keep the CPython
repo tidy, please try to limit the existence of the new branch to, at most,
a few days.
It is recommended to keep a fork of the main repository around, as it allows
simple reversion of all local changes (even “committed” ones) if your local
clone gets into a state you aren’t happy with.
git branch you will see a list of branches.
master is the in-development branch, and is the only branch that receives
new features. The other branches only receive bug fixes or security fixes.
needs backport toX.Y to the pull request.
After the pull request has been merged, miss-islington (bot) will first try to
do the backport automatically. In case that miss-islington is unable to do it,
then the pull request author or the core developer who merged it should look into
backporting it themselves, using the backport generated by cherry_picker.py
as a starting point.
The commit hash can be obtained from the original pull request, or by using
git log on the master branch.
To display the 10 most recent commit hashes and their first line of the commit
message:
git log -10 --onelinePrefix the backport pull request with the branch, and reference the pull request number from
master, for example:
[3.9] bpo-12345: Fix the Spam Module (GH-NNNN)Note that cherry_picker.py adds the branch prefix automatically. Once the backport pull request has been created, remove the
needs backport toX.Y label from the original pull request. (Only Core
Developers and members of the Python Triage Team can apply labels to GitHub
pull requests).
Revert button at the bottom of
the pull request. It will bring up the page to create a new pull request where
the commit can be reverted. It also creates a new branch on the main CPython
repository. Delete the branch once the pull request has been merged.
Always include the reason for reverting the commit to help others understand
why it was done. The reason should be included as part of the commit message,
for example:
Revert bpo-NNNN: Fix Spam Module (GH-111) Reverts python/cpython#111. Reason: This commit broke the buildbot.
●Python »
Python Developer's Guide »