while we have not an 100% agreement to go ahead, I think we should aim for 3.11.
The following steps would be:
- accept the current python3-defaults into
testing (adding 3.11 as supported)
- ask for a transition slot to upload (see #1026825)
python3-defaults with 3.11 as the default
- start the no-change NMUs
- file bug reports.
- fix issues
- let 3.11 as default migrate to testing.
If things don't go as planned, we could default back to 3.10. Mostly that would
be no-change uploads, however in the case of a 3.11 specific fix that doesn't work for 3.10, these fixes would need reverting. I have no idea who many of these we will introduce with this transition.
Also we might want to ask for some freeze exceptions for third party libraries,
that we can't fix before the feature freeze, unfortunately at this point we cannot say which and how many packages would be affected.
thoughts from a concerned maintainer
it seems this email advocates for a "let's wing it"[1] type of transition.
[1] https://en.wiktionary.org/wiki/wing_it
It appears there has been little work in preparing the work to
introduce python3.11 from its maintainer, instead that works has been
pushed downstream to maintainers.
if we continue with the plan as described above, several python libraries/applications maintainers will be left with the short end of
the stick and deal with an unknown amount of issues (upstream fixes
not available, not ready and or/ not released, rushed, etc) with less
than a month from the beginning of the transition freeze[2]
[2] https://release.debian.org/bullseye/freeze_policy.html
[2] also highlights at the very beginning "Plan your changes for
bullseye", this change appears as if it was not planned and we should
be skeptical to proceed without further (and in advance) understanding
of the impact it may have on Bullseye.
Sandro Tosi <morph@debian.org> writes:
thoughts from a concerned maintainer
Sandro, thank you for writing this email.
it seems this email advocates for a "let's wing it"[1] type of
transition.
[1] https://en.wiktionary.org/wiki/wing_it
It appears there has been little work in preparing the work to
introduce python3.11 from its maintainer, instead that works has
been
pushed downstream to maintainers.
if we continue with the plan as described above, several python libraries/applications maintainers will be left with the short end
of
the stick and deal with an unknown amount of issues (upstream fixes
not available, not ready and or/ not released, rushed, etc) with
less
than a month from the beginning of the transition freeze[2]
Agreed. At a bare minimum, complete data from ratt (Rebuild All The
Things) should be required at this point.
[2] https://release.debian.org/bullseye/freeze_policy.html
[2] also highlights at the very beginning "Plan your changes for
bullseye", this change appears as if it was not planned and we
should
be skeptical to proceed without further (and in advance)
understanding
of the impact it may have on Bullseye.
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
It appears there has been little work in preparing the work to
introduce python3.11 from its maintainer, instead that works has been
pushed downstream to maintainers.
if we continue with the plan as described above, several python libraries/applications maintainers will be left with the short end of
the stick and deal with an unknown amount of issues (upstream fixes
not available, not ready and or/ not released, rushed, etc) with less
than a month from the beginning of the transition freeze[2]
[2] also highlights at the very beginning "Plan your changes for
bullseye", this change appears as if it was not planned and we should
be skeptical to proceed without further (and in advance) understanding
of the impact it may have on Bullseye.
There have been rebuilds in Ubuntu that give us some idea of how muchI have some spare time right now, and I am happy to help
work remains. I think it's tractable, but also will have some package >casualties.
There have been rebuilds in Ubuntu that give us some idea of how muchI have some spare time right now, and I am happy to help
work remains. I think it's tractable, but also will have some package casualties.
work on problematic cases, so hopefully nobody will feel left out in
the cold with their favorite packages.
I'm the regular uploader of python3-llvmlite.
Please give up with numba. Its core dependency llvmlite is not even
ready for llvm != 11, while Sid had already get llvm-11 removed.
I have tried to cherry-pick an upstream fix to bump llvmlite's
llvm dependency to 12/14, but the autopkgtest shows numba would
be vastly broken.
Unless they bump LLVM dependency to a newer version: https://github.com/numba/llvmlite/issues/897 https://github.com/numba/llvmlite/pull/830
there is zero chance to get numba in stable. I do not want to
bump LLVM by force and leave a broken package in stable.
llvmlite's python 3.11 support is still on the way: https://github.com/numba/llvmlite/issues/885
One possibility is that we may apply for freeze exception
and wait for the llvmlite v0.40.0 release and see whether
they will bump llvm dependency.
On Thu, 2022-12-22 at 18:46 +0000, Stefano Rivera wrote:
Hi Timo (2022.12.22_12:56:20_+0000)
There have been rebuilds in Ubuntu that give us some idea of how much work remains. I think it's tractable, but also will have some package casualties.I have some spare time right now, and I am happy to help
work on problematic cases, so hopefully nobody will feel left out in
the cold with their favorite packages.
Offhand, the one I most expect trouble with is numba. We were reliant on upstream for the 3.10 transition, and probably will be for 3.11.
Thanks for your help with pony ORM, Timo. I didn't think we'd be able to port that without upstream, but it did end up being tractable.
I'm expecting to have more time in the upcoming weeks, too.
So, release team, I still think we should go ahead!
SR
Hi Timo (2022.12.22_12:56:20_+0000)
There have been rebuilds in Ubuntu that give us some idea of how much work remains. I think it's tractable, but also will have some package casualties.I have some spare time right now, and I am happy to help
work on problematic cases, so hopefully nobody will feel left out in
the cold with their favorite packages.
Offhand, the one I most expect trouble with is numba. We were reliant on upstream for the 3.10 transition, and probably will be for 3.11.
Thanks for your help with pony ORM, Timo. I didn't think we'd be able to
port that without upstream, but it did end up being tractable.
I'm expecting to have more time in the upcoming weeks, too.
So, release team, I still think we should go ahead!
SR
while we have not an 100% agreement to go ahead, I think we should aim for 3.11.
The following steps would be:
- accept the current python3-defaults into
testing (adding 3.11 as supported)
- ask for a transition slot to upload (see #1026825)
python3-defaults with 3.11 as the default
- start the no-change NMUs
- file bug reports.
- fix issues
- let 3.11 as default migrate to testing.
If things don't go as planned, we could default back to 3.10. Mostly that would
be no-change uploads, however in the case of a 3.11 specific fix that doesn't work for 3.10, these fixes would need reverting. I have no idea who many of these we will introduce with this transition.
Also we might want to ask for some freeze exceptions for third party libraries,
that we can't fix before the feature freeze, unfortunately at this point we cannot say which and how many packages would be affected.
Hi Timo (2022.12.22_12:56:20_+0000)
There have been rebuilds in Ubuntu that give us some idea of how much work remains. I think it's tractable, but also will have some package casualties.I have some spare time right now, and I am happy to help
work on problematic cases, so hopefully nobody will feel left out in
the cold with their favorite packages.
Offhand, the one I most expect trouble with is numba. We were reliant on upstream for the 3.10 transition, and probably will be for 3.11.
Thanks for your help with pony ORM, Timo. I didn't think we'd be able to
port that without upstream, but it did end up being tractable.
I'm expecting to have more time in the upcoming weeks, too.
So, release team, I still think we should go ahead!
This has since already been discussed here: the final decision was to "at least try 3.11", which is exactly what we're doing.
FYI, I'm down with only 2 major bugs (I don't mind much if the other 3 RC bugs push the 3 affected packages away from the release, it's just a "would be nice" thing ATM):
If I would create a list mine whould be way longer.
Please share it in this list!
We are constantly beaten by removal from testing warnings
even with Python3.11 as an option and sometimes we simply need to remove that option as a temporary means for bookworm.
Same over here. It's finally looking good for me after 2 months of heavy efforts.
No better solution but better timing which means after bookworm release.
I've read *many* people saying it would be disappointing for them to see their package removed because of Python 3.11. Well, please consider that it would also be very disappointing to *not* have Python 3.11 for those who managed constantly fix issues for it.
The timing was exactly what was discussed during Debconf: it's very annoying that this year, upstream Python release was one month late... we're only trying to deal with it.
Hi Thomas,
Am Thu, Jan 05, 2023 at 01:57:43PM +0100 schrieb Thomas Goirand:
This has since already been discussed here: the final decision was to "at least try 3.11", which is exactly what we're doing.
I admit I was not at site and may be I missunderstood what was finally decided. From my perspective this "at least try" is that we are
actually trying by having 3.11 as additional supported version which has triggered quite some work. We are approaching the Transition and
Toolchain Freeze in 5 days[1]. Given that switching default Python is a transition I wonder how you can assume that this is the right time to
suggest this. I would not have been that astonished if you would have
done so say at first December last year. But now its absolutely clear
that a migration (with the "option" to revert which will cause extra
work) will pour sand into the gears of the release process.
FYI, I'm down with only 2 major bugs (I don't mind much if the other 3 RC bugs push the 3 affected packages away from the release, it's just a "would be nice" thing ATM):
That's a nice situation for the field you are working in.
If I would create a list mine whould be way longer.
Please share it in this list!
#1023965 [src:pandas] pandas FTBFS with Python 3.11 as supported version
#1024031 [src:numba] numba FTBFS with Python 3.11 as supported version
These packages have a sufficient amount of rdepends and usually trigger
lots of other autopkgtest failures in other packages which will keep
them out of testing for quite some time. We could need all helping
hands to fix these ... all noise that will happen afterwards will keep
the relevant teams busy enough.
We are constantly beaten by removal from testing warnings
even with Python3.11 as an option and sometimes we simply need to remove that option as a temporary means for bookworm.
Same over here. It's finally looking good for me after 2 months of heavy efforts.
You mean you are fixing Python 3.10 manually in some packages diverging
what will be default Python?
No better solution but better timing which means after bookworm release.
I've read *many* people saying it would be disappointing for them to see their package removed because of Python 3.11. Well, please consider that it would also be very disappointing to *not* have Python 3.11 for those who managed constantly fix issues for it.
I can understand that we can never satisfy the needs of everybody. My
main problem is the extremely unfortunate timing that is happening now.
The timing was exactly what was discussed during Debconf: it's very annoying
that this year, upstream Python release was one month late... we're only trying to deal with it.
I do not remember that the scchedule was discussed.
* Add 3.11 as a supported Python3 version
was done in python3-defaults (3.10.6-2) at Fri, 11 Nov 2022 11:10:31
+0200. At 12. December Graham suggested on the behalf of the release
team[2] to switch to 3.11. If we would have acted upon this at that
very time I would have considered this quite dense but the last chance
to consider this in line with the "lets try" attempt discussed at
DebConf.
Bug #1026825: python3.11 as default filed right before (21.12.) a series
of holidays in the region of the world where lots of developers will typically reduce their activity which is closely followed by the first
freeze step is IMHO something else. Since I realised that the transition
was started[3] our discussion is a bit useless. I just want to explain
the motivation why I sounded "astonished" since you said that you do
not understood astonishment since we are following the suggested plan.
[1] https://release.debian.org/testing/freeze_policy.html
[2] https://lists.debian.org/debian-python/2022/12/msg00074.html
[3] https://release.debian.org/transitions/html/python3.11-default.html
--
http://fam-tille.de
Am Sat, Jan 07, 2023 at 09:05:21AM +0100 schrieb Andreas Tille:
If I would create a list mine whould be way longer.
Please share it in this list!
#1023965 [src:pandas] pandas FTBFS with Python 3.11 as supported version >> #1024031 [src:numba] numba FTBFS with Python 3.11 as supported version
I'd like to add
#1027851 [src:pytorch] FTBFS with Python 3.11 as default version
also with lots of rdepends.
I did not received any response to my "small" list. What does this
mean for the transition to 3.11 process?
We are constantly beaten by removal from testing warnings
even with Python3.11 as an option and sometimes we simply need to remove >>>> that option as a temporary means for bookworm.
Same over here. It's finally looking good for me after 2 months of heavy >>> efforts.
You mean you are fixing Python 3.10 manually in some packages diverging
what will be default Python?
Any answer to this question?
Bug #1026825: python3.11 as default filed right before (21.12.) a series
of holidays in the region of the world where lots of developers will
typically reduce their activity which is closely followed by the first
freeze step is IMHO something else. Since I realised that the transition
was started[3] our discussion is a bit useless. I just want to explain
the motivation why I sounded "astonished" since you said that you do
not understood astonishment since we are following the suggested plan.
I keep on thinking that the timing is unfortunate and that it
will spoil the whole release process.
#1023965 [src:pandas] pandas FTBFS with Python 3.11 as supported version
#1024031 [src:numba] numba FTBFS with Python 3.11 as supported version
I saw the above 2 were fixed.
I'd like to add
#1027851 [src:pytorch] FTBFS with Python 3.11 as default version
also with lots of rdepends.
So we're back with one single bug. I remember seeing something similar in another package ... (scratching my head...). The latest version of the upstream code has some modifications to this broken Stream.cpp, have you tried to apply them?
Do you have more to share? It's harder to help if you don't ask for it.
IMO, feel free to give a full list of problematic packages in this list, so others may help.
I did not received any response to my "small" list. What does this
mean for the transition to 3.11 process?
As much as I know, we're moving toward having Python 3.11 only in Bookworm. I'm not the person driving it though, and I am not in the best position to make such choice, but I support it (as I would prefer having the nice enhancements of Python 3.11 rather than lagging behind). Hopefully, I wont regret it and wont find more failures in "my" packages.
You mean you are fixing Python 3.10 manually in some packages diverging what will be default Python?
Any answer to this question?
All of my packages hopefully always test with all available versions, and most run autopkgtest. So I was warned early of Py 3.11 failures. They are
all fixed, as much as I know (no opened RC bug remaining...). And no,
forcing Python 3.10 is *NOT* an option, one must fix failures in Python
3.11.
I keep on thinking that the timing is unfortunate and that it
will spoil the whole release process.
I'm sad to read this. Hopefully, this is truth only for some of the packages you care, and the vast majority of the packages are fine? I'm unfortunately not in a good position to tell (I didn't run any survey of broken packages...).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 171:56:33 |
| Calls: | 9,704 |
| Calls today: | 4 |
| Files: | 13,736 |
| Messages: | 6,178,514 |