The Python 3.5 branch has now entered "security fixes only" mode. No
more bugfixes will be accepted into the 3.5 branch.
In keeping with our modern workflow, I have changed the permissions on
the 3.5 branch on Github so that only release managers can accept PRs
into the branch. Please add me to your 3.5 security fix PRs, as I'm the
one responsible for accepting them. (This was already true for the 3.4
I neglected to mention it in the release announcement, but this
transition also means no more binary installers for 3.5 releases. This
signals the end of my interactions with macOS Platform Expert Ned Deily
and Windows Platform Expert Steve Dower when making releases. I just
wanted to mention what a pleasure it has been working with those two
gentlemen for the two Python releases I've RM'd for. They've made me
look good every time.
On behalf of the Python development community and the Python 3.5 release
team, I'm pleased to announce the availability of Python 3.5.4.
Python 3.5.4 is the final 3.5 release in "bug fix" mode. The Python
3.5 branch has now transitioned into "security fixes mode"; all future
improvements in the 3.5 branch will be security fixes only, and no
conventional bug fixes will be merged.
You can find Python 3.5.4 here:
Python 3.4.7 final will be released later today.
If anyone else wants to be on the team to be notified for import-related
PRs then please just let any of us know and we can add you (I'm making
everyone who's a member of a team an admin for that team so we don't have
For those of you who have not noticed, mention-bot is no more. We were
using the free instance that Facebook provided, but it seems to have fallen
over and it doesn't look like it's going to get fixed soon (
But while mention-bot was down, GitHub launched a new feature that serves a
related purpose. While mention-bot tried to guess who should review a PR
based on who has committed (which led some of us to get mentioned a lot
simply from having touched a bunch of files), that didn't guarantee people
got listed as a reviewer when they specifically wanted to be (e.g.
Christian wanting to know about PRs touching our hashing or SSL code).
But GitHub launched CODEOWNERS to cover that latter case (
https://help.github.com/articles/about-codeowners/ ). Now the filename is
misleading since it doesn't necessarily mean someone owns the code (there's
an option to make it feel like that, but we will never flip that on), but
basically what the file does is let us specify who should automatically be
added as a review of a pull request when files changed by the PR match one
of the rules in CODEOWNERS. We have now created the file thanks to Mariatta
started with what we had in our .mention-bot file (which was just some
rules for Christian). But if there are any files you want to automatically
be listed as a reviewer on automatically, then please add an appropriate
rule to that file (remember that being listed as a reviewer doesn't require
that you review else you block a PR from being merged, so don't view it as
some major commitment).
Now to start we can specify individual people. But if there end up being
groups of people who want to be added to reviews on certain topics (e.g.
Eric, Nick, and myself for importlib stuff), then we can create sub-teams
on GitHub of the Python Core team and then that team can be listed for the
rule. To create a team just tell me who is on the team -- all of whom will
be made admins so teams are self-organized post-creation -- and what the
team name should be (e.g. importlib-team). Then you can reference the team
by e.g. @python/importlib-team (I think team names, even when nested, are
not nested when mentioning so we will probably want to have a "-team"
suffix for all teams to make it clear it's a subteam and not to clash with
higher-level teams like @python/asyncio or @python/typing).
When a PR is consistent on several commits, the final commit message
composed by GitHub contains messages of all these commits: "fix typo",
"address yyy comments", "revert zzz". If the initial commit message
contained errors (e.g. absent issue number), it is easy to edit the
title and text of a PR, but the initial commit message lefts unchanged.
GitHub allows to edit the commit message of squashed commit, and please
don't ignore this possibility. Otherwise the commit message in the
repository will be ugly if not worse.