The 3.6 branch no longer accepts bugfixes, so I suggest to remove the “needs backport to 3.6” label from GitHub. It’s not hard to use “git cherry-pick -x SHA1” to backport manually a change without the miss-inlington bot.
Technically, it’s trivial to remove the label (I can remove it), but I would like to check that others agree with that 
I also created a PR for the devguide to mention that 3.6 branch status moved to security-only: https://github.com/python/devguide/pull/442
Since we’ve already removed needs backport to 3.5 I think it makes sense to remove 3.6 label too, so we don’t accidentally create the backport PR.
But perhaps release manager is in better position to decide.
Merging to 3.6 is already blocked for miss-islington.
Yeah, I’m waiting for Ned 
Maybe he would prefer to wait until 3.7.2 is released.
I propose to allow backporting to 3.6 while automatic backporting is possible.
While I’m sure people would appreciate more free support, but I don’t want to burden maintainers (directly or incidentally from having to keep processes alive for 3.6 support) by extending 3.6 support (especially when it’s last-minute and thus not fair to ask Ned to take on more of a RM burden).
See the discussion on the python-committers mailing list with my response here. TL;DR we are not going to change our plans now.
Thanks for the devguide PR, Victor, and for bringing up the backport label question. I will be reviewing all of this over the next couple of days while releasing 3.6.8 and making the transition to security-fix mode.
There were fixes merged to 3.6 in the past few days. Do they become a part of the next source only release for 3.6 ?
3.6 is still open for security fixes only until Dec 2021. So yeah, these fixes will be included in the next source only security release, if the RM decide that such release is needed.
I don’t think that it’s a good ideas to continue to push bugfixes. For example, " [3.6] bpo-24746: Avoid stripping trailing whitespace in doctest fancy diff (GH-10639) #11477" caused a buildbot failure in the 2.7 branch.
If those aren’t security fixes then perhaps they shouldn’t have been merged.But I’m sure Ned will do his due diligence before making a cut.
There are still open 57 PRs with “needs backport to 3.6” label [0] that someone might accidentally merge even with miss-islington’s warning about protected branch in the comments blocking merge. With respect to GitHub branch restriction is this a hard block restricting core devs apart from release manager merging to security fix branches?
This might cause maintenance burden during 3.6 release while filtering out relevant commits. As Victor noted they could possibly cause regressions that have to be reverted/fixed once there is a full run on buildbots with PRs merged. Hence I brought this up here for discussion.
What about documentation fixes? Before moving to GitHub, branches in security fixes only mode were open also for documentation fixes (if a core developer decided that it is worth). But after moving to GitHub it is very hard to fix the documentation in these branches.
I blindly and manually removed the “needs 3.6 backport” from the 57 PRs I didn’t check the content of each PR. So if I made a mistake, just add back the label 
I prefer to restrict changes to the strict minimum, security fixes:
If we agree to only accept security fixes (as stated at https://devguide.python.org/#status-of-python-branches ) I would suggest to remove the “needs 3.6 backport” just to have any risk of mistakes. I expect very very few cherry-picks, so they can be done manually, whereas I expect a high number of “needs 3.6 backport” label added by mistake and I’m already bored of having to repeat that 3.6 no longer accept bugfixes or doc update.
I would like to keep the “needs 3.6 backport” label for the time being. At the moment, I am not sure why GH-11477 was able to be manually merged; it should not have been possible and has now been reverted. No one other than release managers or other repo admins should be able to auto- or manually merge PRs to security branches; please let us know if you find that to not be the case. At this early stage of 3.6 security-fix-only mode, I would prefer if you let the release manager decide whether 3.6 labels should be removed or not, thanks.
@storchaka, as far as I know and can see from the repo, our policy has long been to not backport general documentation changes to security-fix-only branches, certainly long before we migrated to git. See, for example, changes made to the 3.4 branch after it went to security-fix mode. While release managers make occasional exceptions, the rule is as stated in the devguide:
The only changes made to a security branch are those fixing issues exploitable by attackers such as crashes, privilege escalation and, optionally, other issues such as denial of service attacks. Any other changes are not considered a security risk and thus not backported to a security branch. You should also consider fixing hard-failing tests in open security branches since it is important to be able to run the tests successfully before releasing.
No one other than release managers or other repo admins should be able to auto- or manually merge PRs to security branches; please let us know if you find that to not be the case.
Several people other than release managers, like myself, have admin access and can merge to protected branches. For myself I need this in order to see webhook deliveries for the bots.
You can go to https://github.com/python/cpython/settings/collaboration to see who are the Collaborators (and not release managers).