Re: Python 3.11 for bookworm?
There is not yet an accurate estimate of time required to fix the python packages during the transition -- and I still remember the transition from python3.9 -> python3.10 took a very long period that does not seem short enough to be covered by the freeze schedule. 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. 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 think the risk of greatly breaking the release plan outweighs the gain. On Wed, 2022-12-21 at 20:21 -0500, Nicholas D Steeves wrote: > Sandro Tosi 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
Re: Python 3.11 for bookworm?
Sandro Tosi 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 signature.asc Description: PGP signature
Re: Python 3.11 for bookworm?
thoughts from a concerned maintainer On Wed, Dec 21, 2022 at 1:24 PM Matthias Klose wrote: > > 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. from expressions like * "If things don't go as planned" * "no idea who many of these we will introduce with this transition." * "cannot say which and how many packages would be affected" 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. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: Python 3.11 for bookworm?
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. Matthias
Bug#1026825: python3.11 as default
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: debian-python@lists.debian.org Please setup a transition window for python 3.11 as the default python3 version. A tracker is setup at https://release.debian.org/transitions/html/python3.11-default.html Thanks to many Debian and Ubuntu developers, this transition is now finished for Ubuntu, and outstanding bug reports should be filed as https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.11;users=debian-python@lists.debian.org
Re: review for pytest-fail-slow/0.3.0-1
Hi, Some repo issues: * It appears tags were not pushed, as there's no tags at all in the repo - not even for the imported upstream release - although the typical gbp workflow would handle that. That is done now. * The upstream tarball produced by uscan differs from the pristine-tar data. Are you making use of the standard tools for importing new releases, e.g. 'gbp import-orig --pristine-tar --uscan' or similar? This was strange but I found the reason. The upstream repo in github had two .tar.gz files that were slightly different, so I updated the branches to be consistent with uscan. But I am using the standard tools. Then for the packaging itself (which is in pretty good shape): * changelog: please leave the release at UNRELEASED, cf. team policy. * control: + the binary pkg for a pytest plugin is commonly named python3-pytest-; + short description: Pytest plugin to [current description]? * upstream/metadata missing. * no autopkgtest? Should be a trivial yet *very* useful addition, providing early warning for things like compatibility issues with newer pytest releases before packages using the plugin start seeing failures. All are updated as asked, and I created an autopkgtest. Thank you for the feedback! Is there a check list that you follow when reviewing these packages? That can help with future uploads. -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Docu about Salsa workflow
On Wed, 21 Dec 2022, c.bu...@posteo.jp wrote: Hello, sorry for asking. I'm looking or the right document explaining the workflows on Salsa. Am I on the right way here: https://wiki.debian.org/Teams/PythonTeam ? Most projects on Salsa do have three branch names. I need an explanation of them and how they interact. The team policy talks about the three branches and the Git procedures for managing them (using git-buildpackage): https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#git-procedures Scott
Docu about Salsa workflow
Hello, sorry for asking. I'm looking or the right document explaining the workflows on Salsa. Am I on the right way here: https://wiki.debian.org/Teams/PythonTeam ? Most projects on Salsa do have three branch names. I need an explanation of them and how they interact. Kind Christian
