On 12/22/22 02:21, Nicholas D Steeves wrote:
100% +1 I'm especially concerned about how a clear plan was not communicated to other teams--whose work will be broken by the proposed transition, were an exception to be granted. Debian is not a paragon of community if it makes late, unannounced changes that result in a yet-undetermined number of projects being dropped from bookworm's release. If Python 3.11 as the only supported version is a release goal, then the freeze schedule would need to be modified. Regards, Nicholas
Hi Nicholas,While I can agree that it may be harsh, and that some packages wont be fixed in time, I can't let you say that there was only 1 month given, and that all of this comes as a surprise. We've been talking about this since last summer.
On 12/22/22 05:48, M. Zhou wrote: > A significant Python performance improvement in 3.11 is good. > But note, when python performance has really become an issue, > people already have mature solutions, e.g. offloading the > performance critical part onto a compiled language. I don't agree with this either.I'm running large-ish OpenStack swift clusters, where we run up to 18 physical nodes as proxies (eating 100s of requests per seconds). Even a 10% gain would be greatly appreciated for us. There's no "C" improvement here, it's fully in Python... I tried running all Swift services over uwsgi, but it didn't work well (we reverted this type of setup because many things broke).
The fact that a new python process can spawn faster is also really a good thing (so that's not only the interpreter pure speed that I would like to have).
On 12/22/22 05:48, M. Zhou wrote: > Apart from that, package maintainers have their own plans as well. > I believe that at the current stage, many people have assumed that > the next stable will ship python3.10, and have their packages > finalized for freeze already. Making that transition at the current > stage will push a number of maintainers into a rush of updating > their packages again -- in the worst case, the package upstreams > might be not even ready for python 3.11.Well, that's not the first time we are trying to push the latest interpreter close to a release. In fact, this happens on nearly each freeze. Yes, sometimes, there's no upstream fixes yet and you have to write your own. But that's what we do: we maintain packages... and fix bugs when we can.
Since last summer, I fixed maybe about 20 to 30 Python 3.11 issues, sometimes with, and sometimes without help from upstream. And I have about a dozen more to fix in my TODO (see below). I invite everyone to try to do the same, so we can reach that goal.
I also very much would appreciate help on these (which all look like probably related to py3.11):
#1026524 ironic-inspector: FTBFS: AttributeError: '_thread.RLock' object has no attribute 'is_locked' #1026547 python-pypowervm: FTBFS: AssertionError: Expected 'warn' to be called once. Called 2 times.
#1026549 python-pytest-xprocess: FTBFS: tests failed #1026591 cinder: FTBFS: make[1]: pyversions: No such file or directory#1026595 python-murano-pkg-check: FTBFS: TypeError: load_all() missing 1 required positional argument: 'Loader'
#1026610 horizon: FTBFS: tests failed#1026691 bandit: FTBFS: TypeError: load() missing 1 required positional argument: 'Loader' #1026693 cloudkitty: FTBFS: touch: cannot touch '/<<PKGBUILDDIR>>/debian/cloudkitty-doc/usr/share/doc/cloudkitty-doc/html/_static/toggle.js': No such file or directory #1026702 python-cursive: FTBFS: AttributeError: '_RSAPrivateKey' object has no attribute 'signer' #1026705 python-pecan: FTBFS: E AttributeError: 'code' object has no attribute 'co_endlinetable' #1026707 jenkins-job-builder: FTBFS: E: pybuild pybuild:386: test: plugin custom failed with: exit code=1: PYTHON=python3.10 stestr run
BTW, thanks a lot to Lucas Nussbaum for doing the archive rebuilt and finding these out early!
To sum-up: while I'm not 100% on the side of breaking things that close to a release, and would also feel it very painful if one of the above bugs isn't fixed in time, I don't feel like you guys are giving good point of argumentation, or a solution to improve the process. Doko already explained that switching the interpreter (the hard way) is the only viable way to find out the remaining bugs. Do you have a better solution in mind?
Cheers, Thomas Goirand (zigo)
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature