RFC: PEP 608: Coordinated Python release
Hi, I just posted a new PEP for comments, please reply there, rather than by email: https://discuss.python.org/t/rfc-pep-608-coordinated-python-release/2539 PEP 608: Coordinated Python release https://www.python.org/dev/peps/pep-0608/ Abstract: Block a Python release until a compatible version of selected projects is available. The Python release manager can decide to release Python even if a project is not compatible, if they decide that the project is going to be fixed soon enough, or if the issue severity is low enough. Victor -- Night gathers, and now my watch begins. It shall not end until my death.
On 10/25/2019 07:25 AM, Victor Stinner wrote:
I just posted a new PEP for comments, please reply there, rather than by email: https://discuss.python.org/t/rfc-pep-608-coordinated-python-release/2539
PEP 608: Coordinated Python release https://www.python.org/dev/peps/pep-0608/
Abstract:
Block a Python release until a compatible version of selected projects is available.
The Python release manager can decide to release Python even if a project is not compatible, if they decide that the project is going to be fixed soon enough, or if the issue severity is low enough.
[replying here because not everybody uses discuss] -1000 We are not responsible for third-party projects, and allowing them to block our progress is counter-productive. -- ~Ethan~
I think it is more important to have CI that clearly shows the impact of dev versions of the interpreter and core packages. Some of us in the Nixpkgs community had this idea for Python core packages as well (and potentially scientific computing packages, but that's out of scope here). This would need funding though https://discuss.python.org/t/funding-for-ci-for-integrating-development-vers... . On Fri, Oct 25, 2019 at 4:29 PM Victor Stinner <vstinner@python.org> wrote:
Hi,
I just posted a new PEP for comments, please reply there, rather than by email: https://discuss.python.org/t/rfc-pep-608-coordinated-python-release/2539
PEP 608: Coordinated Python release https://www.python.org/dev/peps/pep-0608/
Abstract:
Block a Python release until a compatible version of selected projects is available.
The Python release manager can decide to release Python even if a project is not compatible, if they decide that the project is going to be fixed soon enough, or if the issue severity is low enough.
Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/C3KM3LZI... Code of Conduct: http://python.org/psf/codeofconduct/
On Fri, 25 Oct 2019 at 16:16, Freddy Rietdijk <freddyrietdijk@fridh.nl> wrote:
I think it is more important to have CI that clearly shows the impact of dev versions of the interpreter and core packages. Some of us in the Nixpkgs community had this idea for Python core packages as well (and potentially scientific computing packages, but that's out of scope here). This would need funding though https://discuss.python.org/t/funding-for-ci-for-integrating-development-vers....
Agreed - I would consider having some sort of integration testing for core Python beta and various "important" packages to be a *far* better investment here. As you say, though, it's a big enough piece of work that it probably requires funding in some form. It's also worth noting that even with pre-release testing, there's still the non-trivial problem of getting any necessary fixes implemented and co-ordinated. That's a people-management issue, though, and IMO needs handling flexibly and in a way that's sympathetic to the fact that most of the projects involved are volunteer-based and resource starved. One of my biggest reservations about Victor's proposal is that it's basically removing flexibility and demanding extra testing, with little or no explanation of how we'd make that sustainable. Paul
I replied at https://discuss.python.org/t/rfc-pep-608-coordinated-python-release/2539/9 I would prefer to not split the discussion. I understood that discuss.python.org is now preferred to discuss PEPs. And I don't want to discuss here where PEPs should be discussed :-) Victor Le ven. 25 oct. 2019 à 17:37, Paul Moore <p.f.moore@gmail.com> a écrit :
On Fri, 25 Oct 2019 at 16:16, Freddy Rietdijk <freddyrietdijk@fridh.nl> wrote:
I think it is more important to have CI that clearly shows the impact of dev versions of the interpreter and core packages. Some of us in the Nixpkgs community had this idea for Python core packages as well (and potentially scientific computing packages, but that's out of scope here). This would need funding though https://discuss.python.org/t/funding-for-ci-for-integrating-development-vers....
Agreed - I would consider having some sort of integration testing for core Python beta and various "important" packages to be a *far* better investment here. As you say, though, it's a big enough piece of work that it probably requires funding in some form.
It's also worth noting that even with pre-release testing, there's still the non-trivial problem of getting any necessary fixes implemented and co-ordinated. That's a people-management issue, though, and IMO needs handling flexibly and in a way that's sympathetic to the fact that most of the projects involved are volunteer-based and resource starved.
One of my biggest reservations about Victor's proposal is that it's basically removing flexibility and demanding extra testing, with little or no explanation of how we'd make that sustainable.
Paul
-- Night gathers, and now my watch begins. It shall not end until my death.
participants (4)
-
Ethan Furman -
Freddy Rietdijk -
Paul Moore -
Victor Stinner