[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Python 3.11 for bookworm?



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.
 
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


Reply to: