@smontanaro, please make sure to select the correct base branch when creating backport PRs. If you try to merge a 3.11 backport PR into themain branch (what you originally did here), you end up pinging all active core developers due to how GitHub's CODEOWNERS feature works :)

@smontanaro, please make sure to select the correct base branch when creating backport PRs. If you try to merge a 3.11 backport PR into themain branch (what you originally did here), you end up pinging all active core developers due to how GitHub's CODEOWNERS feature works :)

I was on my 3.11 branch. In addition, thecherry_picker command includes the branch on the command line. I have no idea why the PR in GitHub is against the main branch. I think I'm doing everything right.

The branch was created correctly, based on3.11. The the PR was not, though, itsbase branch wasmain (GitHub is not aware enough to care about long-lived branches and thus choose the correct base branch on its own). How are you opening the PR? If it'scherry_picker opening it on its own (I can't remember whether it does that, it hasn't been working for me for other reasons lately :) ), it may have a bug.

The branch was created correctly, based on3.11. The PR was not, though, itsbase branch wasmain...

Ah, that's the problem. It hadn't occurred to me that there was a choice to make at that step. I thought everything would just be correct. The first time I even tried to make a PR against anything butmain was a few days ago. I clearly need to up my game in this regard. Apologies for the problem.

This sort of splat is common enough that must of us now know to check further emails to see if someone has already handled it before even clicking to do anything. Please keep contributing.

This one was solved by re-basing and close/open to restart tests. Force-pushing sometimes results in a mess that requires closing and starting over with a new PR.

Alex, Zachary: could we ask GH to add a way to clear the reviewer request list? Or either question or refuse to create PRs like this? Or add a hook that calls our codebefore making the PR? EDIT Or have we tried already?

This sort of splat is common enough that must of us now know to check further emails to see if someone has already handled it before even clicking to do anything. Please keep contributing.

+1. Apologies if my first message was overly critical,@smontanaro :)

Alex, Zachary: could we ask GH to add a way to clear the reviewer request list? Or either question or refuse to create PRs like this? Or add a hook that calls our codebefore making the PR? EDIT Or have we tried already?

I recall us giving some informal feedback to GitHub some time ago that it would be nice to introduce some more friction to the PR-making process, to make this kind of thing less common. But I don't know that anything came of it; it might well be worth trying again

No worries. You didn't put me off... In fact:

https://discuss.python.org/t/dis-py-stack-append-vs-stack-push/45330