Currently working on the release of Python 3.8.0rc1
Team, amazing job on getting us back on track over the weekend.
Thank you All release blockers and deferred release blockers solved. And there was relatively little additional activity on the branch -- as expected at this point! Thank you for this, it will help get the release candidate out on time.
I'm working on cutting RC1 today Hopefully all sanity checks, as well as building the source tarball and the binary installers for macOS and Windows will all work out fine and we'll be seeing RC1 out tonight.
RC2 and the date of 3.8.0 gold If we manage to avoid the need for RC2, we will be able to release 3.8.0 on October 14th. If we need an RC2, that will slip by a week. I hope we won't. Ideally RC1 should be identical codewise to 3.8.0.
To help our chances, please avoid any source-related activity on the 3.8 branch from now until the release of 3.8.0. Yes, that also counts for bug fixes unless they are critical. (Yeah, it might be a bit annoying but nobody wants to be the person who introduced a last minute regression in a major release.)
Note I didn't say I forbid any activity. I have no power over you, actually. More importantly though, I trust your judgement if you assess some bug is bad enough the fix absolutely has to get into 3.8.0. Moreover, I specifically said source-related activity because...
3.8.0 is important. To some users it will be the first and the last release in the 3.8 series they will see.
We need you to focus on the docs now Are all your changes properly documented? Did you notice other changes you know of to have insufficient documentation? Can you help with the "What's New" document?
anxiously configure-&&-makingly y'rs
- Ł
On Mon, 30 Sep 2019 at 17:48, Łukasz Langa lukasz@langa.pl wrote:
Team, amazing job on getting us back on track over the weekend.
Thank you All release blockers and deferred release blockers solved. And there was relatively little additional activity on the branch -- as expected at this point! Thank you for this, it will help get the release candidate out on time.
I'm working on cutting RC1 today Hopefully all sanity checks, as well as building the source tarball and the binary installers for macOS and Windows will all work out fine and we'll be seeing RC1 out tonight.
I've filed https://bugs.python.org/issue38326 as a release blocker, as I don't think we should be cutting RCs when changes have been made to a PEP-approved API without any pre-merge design discussion.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 30 Sep 2019, at 16:09, Nick Coghlan ncoghlan@gmail.com wrote:
I've filed https://bugs.python.org/issue38326 as a release blocker, as I don't think we should be cutting RCs when changes have been made to a PEP-approved API without any pre-merge design discussion.
Nick, Victor, as co-authors of said PEP, please reach a decision ASAP.
- Ł
On 9/30/2019 3:48 AM, Łukasz Langa wrote:
To help our chances, please avoid any source-related activity on the 3.8 branch from now until the release of 3.8.0. Yes, that also counts for bug fixes unless they are critical. (Yeah, it might be a bit annoying but nobody wants to be the person who introduced a last minute regression in a major release.)
In the past, x.y.zrc1 has been tagged and branched somehow so that commits to x.y are commits to x.y.z+, the future x.y.(z+1). (I never paid attention to the details). For instance, 3.7 is currently 3.7.4+. As soon as Ned makes 3.7.5rc1, commits to 3.7 will go to 3.7.5+, the future 3.7.6, and will not disturb 3.7.5rc1 until Ned cherry picks them into the rc branch for 3.7.5.
Similarly, 3.8 is currently 3.8.b4+. As soon as you make 3.8.0rc1, if you do it the same way x.y.0rc1 has been done before recently, 3.8 commits should go to 3.8.0+, the future 3.8.1. Nothing should go into 3.8.0 until you pull it in or authorize it for those who know how to put it there (I don't). There should be no need to halt 3.8 activity.
tjr
Hello Łukasz, I consider this one critical enough to get into 3.8: https://bugs.python.org/issue38319 Long story short: shutil.copyfile() and socket.sendfile() are broken on 32-bit platforms for files >= 2GiB. shutil.copyfile() was modified by me in the 3.8 cycle so the bug only affects 3.8 and 3.9.
On Mon, Sep 30, 2019 at 3:48 PM Łukasz Langa lukasz@langa.pl wrote:
Team, amazing job on getting us back on track over the weekend.
*Thank you* All release blockers and deferred release blockers solved. And there was relatively little additional activity on the branch -- as expected at this point! Thank you for this, it will help get the release candidate out on time.
*I'm working on cutting RC1 today* Hopefully all sanity checks, as well as building the source tarball and the binary installers for macOS and Windows will all work out fine and we'll be seeing RC1 out tonight.
*RC2 and the date of 3.8.0 gold* If we manage to avoid the need for RC2, we will be able to release 3.8.0 on October 14th. If we need an RC2, that will slip by a week. I hope we won't. Ideally RC1 should be identical codewise to 3.8.0.
To help our chances, please avoid any source-related activity on the 3.8 branch from now until the release of 3.8.0. Yes, that also counts for bug fixes unless they are critical. (Yeah, it might be a bit annoying but nobody wants to be the person who introduced a last minute regression in a major release.)
Note I didn't say I forbid any activity. I have no power over you, actually. More importantly though, I trust your judgement if you assess some bug is bad enough the fix absolutely has to get into 3.8.0. Moreover, I specifically said source-related activity because...
3.8.0 is important. To some users it will be the first and the last release in the 3.8 series they will see.
*We need you to focus on the docs now* Are all your changes properly documented? Did you notice other changes you know of to have insufficient documentation? Can you help with the "What's New" document?
anxiously configure-&&-makingly y'rs
- Ł
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/A... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Giampaolo - http://grodola.blogspot.com
I merged it. In the future: you can use priorities on BPO issues to make it more visible.
- Ł
On 1 Oct 2019, at 07:03, Giampaolo Rodola' g.rodola@gmail.com wrote:
Hello Łukasz, I consider this one critical enough to get into 3.8: https://bugs.python.org/issue38319 https://bugs.python.org/issue38319 Long story short: shutil.copyfile() and socket.sendfile() are broken on 32-bit platforms for files >= 2GiB. shutil.copyfile() was modified by me in the 3.8 cycle so the bug only affects 3.8 and 3.9.
On Mon, Sep 30, 2019 at 3:48 PM Łukasz Langa
mailto:lukasz@langa.pl> wrote: Team, amazing job on getting us back on track over the weekend. Thank you All release blockers and deferred release blockers solved. And there was relatively little additional activity on the branch -- as expected at this point! Thank you for this, it will help get the release candidate out on time.
I'm working on cutting RC1 today Hopefully all sanity checks, as well as building the source tarball and the binary installers for macOS and Windows will all work out fine and we'll be seeing RC1 out tonight.
RC2 and the date of 3.8.0 gold If we manage to avoid the need for RC2, we will be able to release 3.8.0 on October 14th. If we need an RC2, that will slip by a week. I hope we won't. Ideally RC1 should be identical codewise to 3.8.0.
To help our chances, please avoid any source-related activity on the 3.8 branch from now until the release of 3.8.0. Yes, that also counts for bug fixes unless they are critical. (Yeah, it might be a bit annoying but nobody wants to be the person who introduced a last minute regression in a major release.)
Note I didn't say I forbid any activity. I have no power over you, actually. More importantly though, I trust your judgement if you assess some bug is bad enough the fix absolutely has to get into 3.8.0. Moreover, I specifically said source-related activity because...
3.8.0 is important. To some users it will be the first and the last release in the 3.8 series they will see.
We need you to focus on the docs now Are all your changes properly documented? Did you notice other changes you know of to have insufficient documentation? Can you help with the "What's New" document?
anxiously configure-&&-makingly y'rs
- Ł
python-committers mailing list -- python-committers@python.org mailto:python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org mailto:python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/A... https://mail.python.org/archives/list/python-committers@python.org/message/A... Code of Conduct: https://www.python.org/psf/codeofconduct/ https://www.python.org/psf/codeofconduct/
-- Giampaolo - http://grodola.blogspot.com http://grodola.blogspot.com/
Hi Łukasz,
Le lun. 30 sept. 2019 à 16:32, Łukasz Langa lukasz@langa.pl a écrit :
On 30 Sep 2019, at 16:09, Nick Coghlan ncoghlan@gmail.com wrote:
I've filed https://bugs.python.org/issue38326 as a release blocker, as I don't think we should be cutting RCs when changes have been made to a PEP-approved API without any pre-merge design discussion.
Nick, Victor, as co-authors of said PEP, please reach a decision ASAP.
Last Friday, I sent an python-dev to get feedback since I dislike modifying a PEP which is already approved and I wasn't sure of the design of my change (stable ABI for PyConfig).
There was an interesting discussion and it seems like we all agreed to abandon the whole idea of a stable ABI, so I removed PyConfig.struct_size. The change is already merged into 3.8 and the PEP has been updated again.
Nick approved and merged my PRs which means that we agreed the on solution ;-)
Victor
Night gathers, and now my watch begins. It shall not end until my death.
On 30 Sep 2019, at 20:43, Terry Reedy tjreedy@udel.edu wrote:
On 9/30/2019 3:48 AM, Łukasz Langa wrote:
To help our chances, please avoid any source-related activity on the 3.8 branch from now until the release of 3.8.0. Yes, that also counts for bug fixes unless they are critical. (Yeah, it might be a bit annoying but nobody wants to be the person who introduced a last minute regression in a major release.)
In the past, x.y.zrc1 has been tagged and branched somehow so that commits to x.y are commits to x.y.z+, the future x.y.(z+1). (I never paid attention to the details). For instance, 3.7 is currently 3.7.4+. As soon as Ned makes 3.7.5rc1, commits to 3.7 will go to 3.7.5+, the future 3.7.6, and will not disturb 3.7.5rc1 until Ned cherry picks them into the rc branch for 3.7.5.
Similarly, 3.8 is currently 3.8.b4+. As soon as you make 3.8.0rc1, if you do it the same way x.y.0rc1 has been done before recently, 3.8 commits should go to 3.8.0+, the future 3.8.1. Nothing should go into 3.8.0 until you pull it in or authorize it for those who know how to put it there (I don't). There should be no need to halt 3.8 activity.
Right, this is what we were doing and it's what we'll be doing this time around, too.
However, I feel that the release candidate for a .0 version is rather crucial. Cherry-picking changes to the gold release from an active support branch has non-zero risk of unexpected consequences. That can be due to non-trivial relationships between new commits or due to the release manager messing up the cherry-pick.
Another complication is a post-release merge conflict due to cherry picks.
This is why the overall recommendation I received from the more experienced release managers is that if there's too much activity on the branch we should release another preview. I agree with that, otherwise it gets too messy.
...but I don't want another RC if we can help it :-)
- Ł
participants (5)
-
Giampaolo Rodola'
-
Nick Coghlan
-
Terry Reedy
-
Victor Stinner
-
Łukasz Langa