Is it time to promote "free threaded" CI and buildbots?

With the official acceptance of PEP 703, and the track record of stability of the free-threaded CI workflows and the Linux & MacOS buildbots - is it time to promote the free-threaded CI?

  1. Mark the buildbots as “stable”?
  2. Trigger the free-threaded CI workflows unconditionally (currently they are triggered only when the “topic-free-threaded” label is present)?
  3. Remove the free-threaded workflows from the allowed failures list?

On that subject - is there need of additional buildbots for this purpose? I recently did some hefty upgrades to the host system that the amd64-debian-root buildbot runs on, so there’s capacity for another if desired.

1 Like

The existing Linux builders only cover ubuntu, so adding debian to the mix would be nice! If we add more free-threaded Linux buildbot builders, I’d like to cover configurations that aren’t already covered, i.e., one of:

  • PGO
  • PGO + LTO
  • Shared
  • Sanitizers

Yes, I think we should have the free-threaded CI to be on par with old GIL CI. So “yes” to all your three questions.

The PEP 703 acceptance makes clear that it’s experimental to begin with, but we definitely want to ship something with 3.13, and it’s only six months until the beta freeze.

We have no idea how long each of the three phases will be, but community involvement and feedback is essential for progress, and for success. The more we can include in each release, the better, then we can get more feedback and adapt, and hopefully shorten each phase.

This means we can’t really afford regressions in the free-threaded builds caused by “normal” PRs that didn’t run the free-threaded CI.

Finally, we’re expecting C-extension libraries to test on both free-threaded and GIL builds, so we should also experience the pain reality of double testing :slight_smile: (I don’t think it will be too bad, but let’s find out.)

1 Like