Re: Please avoid non-bugfix changes during the beta phase
My two cents: I think this should be a little more liberal. At beta 1, freeze the addition of new features but continue to tweak the implementation with code clean-ups, additional tests, algorithmic improvements, and better docs. For many of the devs (and users), the first time we get to exercise and interact with some of the new features is during the beta — that is our chance to improve and stabilize it before it goes out the door. If a new API proves awkward in some way, the time to find out and improve it is during the beta. Ideally, we would like both the API and implementation to mature a bit before the release (first draft != final copy). A release candidate is different — that is close to an across-the-board freeze. Once the release happens, bug fixes and documentation tweaks will continue to be checked in for the next micro-release.
Side note: One problem we have is that so few people actually exercise the beta and give useful feedback. To me, the chief value of a public beta is that people get to try it out before everything is set it stone. And reason for having multiple betas is so that we can iterate. If not, perhaps we should just have a single beta, frozen except for bugfixes.
Raymond
Le mar. 7 juil. 2020 à 04:21, Raymond Hettinger <raymond.hettinger@gmail.com> a écrit :
At beta 1, freeze the addition of new features but continue to tweak the implementation with code clean-ups, (...)
IMHO clean-ups should stop after beta1. Only the master branch should receive cleanup changes. A clean-up doesn't bring any value to users and is a risk of regression, as Lukasz explained in his message.
It's clearly explained in the devguide: https://devguide.python.org/devcycle/#beta
"After a first beta release is published, no new features are accepted. Only bug fixes can now be committed."
Victor
Night gathers, and now my watch begins. It shall not end until my death.
On Mon, Jul 6, 2020 at 7:21 PM Raymond Hettinger <raymond.hettinger@gmail.com> wrote: <snip>
If not, perhaps we should just have a single beta, frozen except for bugfixes.
+1 for having betas frozen, except for bug fixes. But the bug fixes need to go somewhere, so I propose to have yet another frozen beta (if there are bug fixes, of course). Oh wait, that's exactly our current workflow!
Yury
It’s true that as releases get closer to final, more people will start exercising them. However, you really don’t have to wait. I maintain “official” Linux (Ubuntu) Docker images that contain all the latest releases (including alphas and betas), and the git head of the development branch at the time of the image builds.
https://gitlab.com/python-devs/ci-images/-/tree/master
I keep these up-to-date on every new maintenance release, alpha, beta, rc, and final, for Python 2.7, and 3.4 through 3.10. I use this image in my own open source code’s CI, and you can too! Unfortunately, we can’t do the same with Windows, but I’ve cracked the nut to get pretty good coverage for Windows releases too. Here for example is flufl.lock’s .gitlab-ci.yml file:
https://gitlab.com/warsaw/flufl.lock/-/blob/master/.gitlab-ci.yml
I need to extend that to 3.9 pre-releases, via python.org downloads rather than nuget.
So, it’s entirely possible to test your stuff against pre-release versions, and I highly encourage it.
That said, I also think that the general rule of only bug fix changes post beta 1 is the right policy. For other changes, or anything that you think straddles the line between bug fix and non-bug fix, ask the Release Manager. The RM’s primary role at this time is to ensure the stability of the final release. Their judgement is critical to the success of the final release, so ask! CC the RM on the PR and request their approval and comment.
I’ll also say that I personally give the RM a lot of latitude and authority to unilaterally revert any change they are not comfortable with. If the change author and RM cannot agree on whether a post-beta change is appropriate, you can escalate to the Steering Council.
Cheers, -Barry
On Jul 6, 2020, at 19:21, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
My two cents: I think this should be a little more liberal. At beta 1, freeze the addition of new features but continue to tweak the implementation with code clean-ups, additional tests, algorithmic improvements, and better docs. For many of the devs (and users), the first time we get to exercise and interact with some of the new features is during the beta — that is our chance to improve and stabilize it before it goes out the door. If a new API proves awkward in some way, the time to find out and improve it is during the beta. Ideally, we would like both the API and implementation to mature a bit before the release (first draft != final copy). A release candidate is different — that is close to an across-the-board freeze. Once the release happens, bug fixes and documentation tweaks will continue to be checked in for the next micro-release.
Side note: One problem we have is that so few people actually exercise the beta and give useful feedback. To me, the chief value of a public beta is that people get to try it out before everything is set it stone. And reason for having multiple betas is so that we can iterate. If not, perhaps we should just have a single beta, frozen except for bugfixes.
Raymond
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/E... Code of Conduct: https://www.python.org/psf/codeofconduct/
On 2020-07-07 21:35, Barry Warsaw wrote:
It’s true that as releases get closer to final, more people will start exercising them. However, you really don’t have to wait. I maintain “official” Linux (Ubuntu) Docker images that contain all the latest releases (including alphas and betas), and the git head of the development branch at the time of the image builds.
https://gitlab.com/python-devs/ci-images/-/tree/master
I keep these up-to-date on every new maintenance release, alpha, beta, rc, and final, for Python 2.7, and 3.4 through 3.10. I use this image in my own open source code’s CI, and you can too! Unfortunately, we can’t do the same with Windows, but I’ve cracked the nut to get pretty good coverage for Windows releases too. Here for example is flufl.lock’s .gitlab-ci.yml file:
https://gitlab.com/warsaw/flufl.lock/-/blob/master/.gitlab-ci.yml
I need to extend that to 3.9 pre-releases, via python.org downloads rather than nuget.
So, it’s entirely possible to test your stuff against pre-release versions, and I highly encourage it.
Many of these also get into Fedora (all alphas/betas/RCs go into Rawhide rather fast; 3.X.0 alphas/betas/RCs go into stable Fedora updates). And we do our best to build almost 4000 packages with the 3.X.0 alpha/beta/RCs, with many of the builds running test suites.
Unfortunately, "test your stuff" tends to only find regressions. New features aren't too useful if you need to support stable Python releases, so they're not tested very much with the betas/RCs.
On Tue, Jul 7, 2020 at 9:41 PM Barry Warsaw <barry@python.org> wrote:
That said, I also think that the general rule of only bug fix changes post beta 1 is the right policy. For other changes, or anything that you think straddles the line between bug fix and non-bug fix, ask the Release Manager. The RM’s primary role at this time is to ensure the stability of the final release. Their judgement is critical to the success of the final release, so ask! CC the RM on the PR and request their approval and comment.
I’ll also say that I personally give the RM a lot of latitude and authority to unilaterally revert any change they are not comfortable with. If the change author and RM cannot agree on whether a post-beta change is appropriate, you can escalate to the Steering Council.
For the record, the Steering Council discussed this topic last night, and this is also the official SC standpoint. I would like to think it needn't be said, but to be on the safe side: the RMs are in charge of the release, and the policies they have set should be followed. If you disagree with a RM and can't resolve it yourself, escalate to the SC.
-- Thomas Wouters <thomas@python.org>
Hi! I'm an email virus! Think twice before sending your email to help me spread!
On Mon, Jul 6, 2020 at 7:21 PM Raymond Hettinger < raymond.hettinger@gmail.com> wrote:
My two cents: I think this should be a little more liberal. At beta 1, freeze the addition of new features but continue to tweak the implementation with code clean-ups, additional tests, algorithmic improvements, and better docs. For many of the devs (and users), the first time we get to exercise and interact with some of the new features is during the beta — that is our chance to improve and stabilize it before it goes out the door. If a new API proves awkward in some way, the time to find out and improve it is during the beta. Ideally, we would like both the API and implementation to mature a bit before the release (first draft != final copy). A release candidate is different — that is close to an across-the-board freeze. Once the release happens, bug fixes and documentation tweaks will continue to be checked in for the next micro-release.
I've occasionally left it up to Łukasz to add the "needs 3.9 backport" label to a PR of mine. That seems a good way to keep the release manager happy. :-)
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On 07Jul2020 0321, Raymond Hettinger wrote:
My two cents: I think this should be a little more liberal. At beta 1, freeze the addition of new features but continue to tweak the implementation with code clean-ups, additional tests, algorithmic improvements, and better docs.
All of those things are allowed during beta, provided the public facing API does not change.
And if you identify a genuine problem, I think you'll find the policy is actually more liberal than you suggest ;) It just requires RM involvement to keep the rate of change under control, rather than letting anyone check in their "essential" improvements at any time.
As for the rest of your suggestions, I agree, but "we" had the release cycle discussion last year and decided that making the next major release come up sooner (12 months instead of 18) was the best way to solve those concerns.
Cheers, Steve
participants (8)
-
Barry Warsaw -
Guido van Rossum -
Petr Viktorin -
Raymond Hettinger -
Steve Dower -
Thomas Wouters -
Victor Stinner -
Yury Selivanov