Re: Python 3.11 for bookworm?
Am Sat, Jan 07, 2023 at 09:05:21AM +0100 schrieb Andreas Tille:
> 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.
How will we decide whether the "at least try 3.11" is success or fail?
Did we defined anything I might have missed in terms of number of
packages that need to pass or number of packages we shoule not loose?
> > 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
I'd like to add
#1027851 [src:pytorch] FTBFS with Python 3.11 as default version
also with lots of rdepends.
> 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.
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?
> > > 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.
I keep on thinking that the timing is unfortunate and that it
will spoil the whole release process.
Kind regards
Andreas.
>
> [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
>
>
--
http://fam-tille.de
Reply to: