Matthias Klose writes: > No, you can't see that with CPython's CI alone. The Debian and > Ubuntu build machines trigger CI tests per architecture for around > 3000 packages depending on python3.9, using the just built > python3.9, and without rebuilding these packages. That's where I > see the 32bit failures.
Thank you, that's what I wanted to know. > How would delaying the release schedule have helped with the issue > that we just saw? I mean to have a period between the announcement of the release date, and the actual release. So it works the same way an rc would, except not rolling the tarball etc. For almost zero maintainer effort, tag it "rc", give you a few days to run your tests on builds from git. If you (and others) don't report a problem, he tags "final" and then produces tarballs, installers, etc to the extent those things are done at this point in the version's lifecycle. Distros could either drop the "rc" in hopes that this commit will indeed be final (and reroll their release if bugs are found), or they could use the sha1 as identifier for the specific commit instead of stuff like "rc" in versioning the package. (I'm brainstorming, this is *not* a thought-out recommendation!) See also Terry Reedy's post for a different explanation of what I believe is the same idea. Steve _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/RHBTR6ICP5LKRXAAX4I4I6UBSMZXB3O3/ Code of Conduct: http://python.org/psf/codeofconduct/
