https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285957
--- Comment #72 from Matthias Andree <[email protected]> --- Note that an -exp run isn't going to dig up all failures. There will be run-time fallout because we do not usually exercise all the .py files we package. Some class attributes may have changed, for instance. Now that Warner opened this Bugzilla PR's discussion to the future versions... The large number of disruptive changes is exacerbated by the attempt of having half a dozen of parallel Python versions without any attempts of pushing the burden to maintain niche ports out, whilst at the same time pushing potential contributors to the side and stomping over them without giving alignments, directions, anything. Just for the fun of it, someone try getting their favorite Python ports installed for 3.13t (t for free-threaded). They'll be in for a very bumpy ride and many ports will fall off the cart. BTDT. Back to future planning: 1. The attempt to do more work in less time whilst disappointing volunteers from stomping over them without communication will fail. Instead of opening up the team and plans to attract contributors, more work is centralized onto the already-overloaded python team and that's... showing. 2. Having 3.10 3.11 3.12 3.13 3.14 as mainline, 3.13t as a pretty incompatible variant and 3.15 beta as preparation is quite a unique luxury FreeBSD is trying to afford but maneuvered into a thicket of dependencies. 3a. The other unique approach in FreeBSD is trying to package the world, the cheese shop, the Sun, the Moon, and their siblings as native packages. And everything's supposed to work through all versions? 3b. Upstream and many other parties are either focusing on *one* recent Python version (one in mainstream support, as opposed to security support), and/or packaging only central builder stuff such as venv, pip, wheel, thereabouts, and then defer the rest to use virtual environments for the deployments. Proposals: do a bulk order of "DEPRECATED" tags and slap them onto niche ports that break on newer setuptools or newer python versions with a live FreeBSD and/or upstream maintainer to assist, or that won't work with Python 3.13 today. (Repeat for py-* ports incompatible with 3.14 as soon as 3.13 will be demoted from upstream mainline to security support.) Add DEPRECATED to 3.11 IN JUNE, BEFORE 2026Q3 branches, so everyone knows what's coming, and consider deprecating early. We might want to sunset it the same day we sunset 3.10 so we get rid of holdups sooner. And now it turns out to be larger than "we" anticipated. => Then "we" is too few, "we're trying" whilst letting certain roles go out of hand and push long-term contributors to the side in stark violation of the portmgr charter, with years of failed communication, that is also a seclusive approach - and you never learn how many people have silently turned away without even offering their support. You don't see them up high in the ivory tower. So can we A. write down the top three (or five, I don't mind) pain spots from the make-3.11-default and make-3.12-default efforts down so we can take a more strategic approach... B. transition FreeBSD Python ports from a "do heavier lifting, more grunt work" approach to a more architectural and strategic attack angle for 3.13 and 3.14 to come? -- You are receiving this mail because: You are the assignee for the bug.
