Clarify which commit hash is used for backporting #254
Conversation
Move ``Backporting Merged Changes`` section to right after the ``Accepting and Merging a Pull Request`` Closes python#238
|
|
||
| The commit hash for backporting is the squashed commit that was merged to | ||
| the ``master`` branch. On the merged pull request, scroll to the bottom of the | ||
| page. Find the event that says something like:: |
There was a problem hiding this comment.
When I resolved conflict while cherry-picking to 3.6 branch, I want to use squash commit of 3.6 branch
for backporting to 3.5.
There was a problem hiding this comment.
When backporting the squashed commit from master, we get to keep the reference to the original PR on master, so bedevere-bot can remove the needs backport to .. labels.
Does this happen when backporting from 3.6 to 3.5?
There was a problem hiding this comment.
It should - the trick in this case is that the "needs backport to 3.5" label should go on the backport PR against the 3.6 branch, rather than the original PR against master.
There was a problem hiding this comment.
I think this makes things complicated for everyone.
If a core dev wants to backport from 3.6 to 3.5, they can do that at their own discretion, while making sure that labels are updated accordingly.
For everyone else (non core-devs backporting their own PR) I think it's best to recommend backporting from master.
There was a problem hiding this comment.
Right, the only time it makes sense if when the backport from master fails, and even then, it only applies for security fixes, or the times when we have two full maintenance branches open (i.e. from beta 1 of the upcoming stable through to the release of that branch and the subsequent final full maintenance release of the now previous stable branch).
However, now that we branch at beta, we're likely to spend around 1/3rd of the time in that state.
There was a problem hiding this comment.
@Mariatta Clarifying: I don't think the above needs to be covered in this PR, but there are cases where we want to do X.Y -> X.Y-1 backports, rather than backporting directly from master.
There was a problem hiding this comment.
Thanks :) I'm going to merge this.
- Clarify which commit hash is used for backporting - Move ``Backporting Merged Changes`` section to right after the ``Accepting and Merging a Pull Request`` - Mention the git fetch upstream & git rev-parse combo Closes python#238
Move
Backporting Merged Changessection to right after theAccepting and Merging a Pull RequestCloses #238