Hello! I just proposed a PR with a small fix to the docs. I'd like to know the procedure to land it. https://github.com/python/cpython/pull/21851 It's super small, so no bug is opened for it, and IMO no mention is needed in the NEWS for the fix. It's waiting for a "core review", which is a good thing (and by all means welcomed). But as we're saturated of PRs, the fix is small, and I'm a core developer myself... shall I wait for a review from another core developer, or should I just land it? Thanks!! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org.ar/ Twitter: @facundobatista
On Thu, Aug 13, 2020 at 12:51 PM Facundo Batista <facundobatista@gmail.com> wrote:
It's waiting for a "core review", which is a good thing (and by all means welcomed). But as we're saturated of PRs, the fix is small, and I'm a core developer myself... shall I wait for a review from another core developer, or should I just land it?
As a core dev you can still merge it yourself without needing to wait for review, even when it has the "awaiting core review" label.
El jue., 13 de ago. de 2020 a la(s) 16:55, Mariatta (mariatta@python.org) escribió:
On Thu, Aug 13, 2020 at 12:51 PM Facundo Batista <facundobatista@gmail.com> wrote:
It's waiting for a "core review", which is a good thing (and by all means welcomed). But as we're saturated of PRs, the fix is small, and I'm a core developer myself... shall I wait for a review from another core developer, or should I just land it?
As a core dev you can still merge it yourself without needing to wait for review, even when it has the "awaiting core review" label.
Awesome, thanks for the help. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org.ar/ Twitter: @facundobatista
El jue., 13 de ago. de 2020 a la(s) 17:32, Facundo Batista (facundobatista@gmail.com) escribió:
As a core dev you can still merge it yourself without needing to wait for review, even when it has the "awaiting core review" label.
Awesome, thanks for the help.
I'll create two new PRs, for 3.8 and 3.9, and when landed remove the "need backport tags" you added... a couple of questions, though: a) is it ok to touch 3.9, as it's in rc1? b) shall I create two brand new branches for those PRs, or there's some way in github/git to "just propose this same change to the other branches"? Thanks! (sorry for the simplicity of the questions, but it was a long time since I touched Python core, and infrastructure changed so much!) -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org.ar/ Twitter: @facundobatista
El jue., 13 de ago. de 2020 a la(s) 17:41, Facundo Batista (facundobatista@gmail.com) escribió:
El jue., 13 de ago. de 2020 a la(s) 17:32, Facundo Batista (facundobatista@gmail.com) escribió:
As a core dev you can still merge it yourself without needing to wait for review, even when it has the "awaiting core review" label.
Awesome, thanks for the help.
I'll create two new PRs, for 3.8 and 3.9, and when landed remove the "need backport tags" you added... a couple of questions, though:
a) is it ok to touch 3.9, as it's in rc1?
b) shall I create two brand new branches for those PRs, or there's some way in github/git to "just propose this same change to the other branches"?
Thanks!
(sorry for the simplicity of the questions, but it was a long time since I touched Python core, and infrastructure changed so much!)
Jaja, the bots came to my rescue! There I backported the changes. I love all that automation, thanks for workin on that. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org.ar/ Twitter: @facundobatista
when landed remove the "need backport tags" you added...
If done correctly, the "needs backport .." labels got removed automatically. We have detailed info here: https://devguide.python.org/committing/#backporting-changes-to-an-older-vers... a) is it ok to touch 3.9, as it's in rc1? Yeah bug fixes are accepted to the maintenance branches. I think your PR does count as documentation bug fix, so it should be ok to backport to 3.9
b) shall I create two brand new branches for those PRs, or there's some way in github/git to "just propose this same change to the other branches"?
In most cases the bot can handle it simply by adding the "needs backport " label. But for more complicated situations, please use the cherry_picker.py command line tool. The documentation on how to do it is here: https://github.com/python/cherry-picker#cherry-picking
On 8/13/2020 9:56 PM, Mariatta wrote:
a) is it ok to touch 3.9, as it's in rc1?
Yeah bug fixes are accepted to the maintenance branches. I think your PR does count as documentation bug fix, so it should be ok to backport to 3.9
At this stage, changes to the 3.9 branch won't go into the 3.9.0 release unless you specifically ask Łukasz to include them (though he does have a habit of acting out of his own initiative and including them anyway :) ). Which means you can freely merge anything you like for 3.9.1, provided it's okay for a maintenance branch (in your judgement, which is part of being a core dev, but feel free to ask others for advice if you're not sure). Cheers, Steve
On 8/13/2020 4:56 PM, Mariatta wrote:
when landed remove the "need backport tags" you added...
If done correctly, the "needs backport .." labels got removed automatically. We have detailed info here: https://devguide.python.org/committing/#backporting-changes-to-an-older-vers...
The backport bot occasionally fails, sometimes for external reasons. If you hit a problem, you can ask me for help as I have probably hit all the failure modes by now.
a) is it ok to touch 3.9, as it's in rc1?
Yeah bug fixes are accepted to the maintenance branches. I think your PR does count as documentation bug fix, so it should be ok to backport to 3.9
Release candidates are done from a separate release branch. I believe that commits now to 3.9 will only appears in 3.9.0rc2 (or 3.9.0) if the release manager cherry-picks them into the 3.9.0 release branch. Otherwise, 3.9.1. Doc fixes usually appear online within a day, so that pulling them into the release branch should only affects the frozen offline copy.
b) shall I create two brand new branches for those PRs, or there's some way in github/git to "just propose this same change to the other branches"?
In most cases the bot can handle it simply by adding the "needs backport " label. But for more complicated situations, please use the cherry_picker.py command line tool. The documentation on how to do it is here: https://github.com/python/cherry-picker#cherry-picking
AFAIK, every PRs is done from its own branch. Backports are done on usually shortlived branches. Cherry-picker names them backport-XXXXXXX-3.x, where XXXXXXX is the first 7 hex digits of the commit and 'x' is the target version. But that has no significance to github. -- Terry Jan Reedy
El jue., 13 de ago. de 2020 a la(s) 18:42, Terry Reedy (tjreedy@udel.edu) escribió:
The backport bot occasionally fails, sometimes for external reasons. If you hit a problem, you can ask me for help as I have probably hit all the failure modes by now.
Thanks! One of the backport failed so I (per the bot's suggestion) learned and used the cherry-picker tool. But while doing that Victor kicked the bot a little, and that time it worked ok... Thanks for the help, everybody! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org.ar/ Twitter: @facundobatista
On 13/08/2020 21:32, Facundo Batista wrote:
El jue., 13 de ago. de 2020 a la(s) 16:55, Mariatta (mariatta@python.org) escribió:
On Thu, Aug 13, 2020 at 12:51 PM Facundo Batista <facundobatista@gmail.com> wrote:
It's waiting for a "core review", which is a good thing (and by all means welcomed). But as we're saturated of PRs, the fix is small, and I'm a core developer myself... shall I wait for a review from another core developer, or should I just land it?
As a core dev you can still merge it yourself without needing to wait for review, even when it has the "awaiting core review" label.
Awesome, thanks for the help.
This link may be helpful, to the relevant part of the dev-guide is this one: https://devguide.python.org/devcycle/#beta . Peer reviews become mandatory at rc1 and are at your discretion before that, is how I read it. It will seem odd that I should know or care about this, not having any relevant rights over CPython, but I'm trying to adopt it in the projects where I do. Jeff Allen
Jeff Allen writes:
It will seem odd that I should know or care about this, not having any relevant rights over CPython, but I'm trying to adopt it in the projects where I do.
But you do have a relevant right: to state your opinion about the governance of the project, both the values and the procedures. And I'm glad you share your knowledge (and the implicit opinion that (C)Python is doing well enough to be worth emulating). I wish more people would study up on governance! Steve
participants (6)
-
Facundo Batista -
Jeff Allen -
Mariatta -
Stephen J. Turnbull -
Steve Dower -
Terry Reedy