Document backport and cherry-pick labels #126
Comments
|
+1 from me. We probably need to wait for a bit to settle on the exact workflow before starting to document it. We could probably cover the GitHub part in http://cpython-devguide.readthedocs.io/committing.html#backporting-changes-to-python-3-6-or-older-version (or split it to two separate subsections?)
+1. This is also my assumption. |
Mariatta
added a commit
that referenced
this issue
Mar 17, 2017
- reference the Git bootcamp page - recommend cherry_picker.py - explain backport/cherry-pick labels Closes #126
Mariatta
added a commit
that referenced
this issue
Mar 17, 2017
- reference the Git bootcamp page - recommend cherry_picker.py - explain backport/cherry-pick labels Closes #126
AA-Turner
pushed a commit
to AA-Turner/devguide
that referenced
this issue
Jun 17, 2022
- reference the Git bootcamp page - recommend cherry_picker.py - explain backport/cherry-pick labels Closes python#126
kitarefake
added a commit
to kitarefake/devguide
that referenced
this issue
Jul 15, 2024
- reference the Git bootcamp page - recommend cherry_picker.py - explain backport/cherry-pick labels Closes python/devguide#126
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There should be a documentation explaining what to do with the labels
needs backport to X.Yandcherry-pick for X.Y. Perhaps as a new section in committing.rst?I think this is the current workflow: (as discussed in python/core-workflow#23)
needs backport to X.Ylabel to the PR againstmaster.masterPR is approved and merged, create the cherry-pick PR.needs backport to X.Ylabel frommasterPRcherry-pick for X.Yto the cherry-pick PR.[X.Y]Where
X.Yis one of the maintenance branches, e.g.2.7,3.5,3.6Related question: Can I assume that the core developer who merged the
masterPR will do the backport?Thanks :)
The text was updated successfully, but these errors were encountered: