Mark NoGIL Linux & MacOS builders as stable #444
Conversation
| @@ -89,6 +91,7 @@ | |||
|
|
|||
| # macOS x86-64 clang | |||
| ("x86-64 macOS", "billenstein-macos", UnixBuild), | |||
| ("x86-64 MacOS Intel NoGIL", "itamaro-macos-intel-aws", UnixNoGilBuild), | |||
There was a problem hiding this comment.
If free-threaded CIs are triggered anyway, Can we update this buildbot as refleak checker?
There was a problem hiding this comment.
afaik the buildbot test suite is more comprehensive than the equivalent CI test suite (e.g. due to --fast-ci flag for example), so there's value in a buildbot builder with "equivalent configuration". I also believe the release manager considers the buildbot statuses when making release decisions, not GitHub Actions.
I also noticed there are no refleak builders for MacOS at all (for the default build) -- would it be valuable to add such builders? (for default and/or nogil)
There was a problem hiding this comment.
afaik the buildbot test suite is more comprehensive than the equivalent CI test suite
I see!
I also noticed there are no refleak builders for MacOS at all (for the default build) -- would it be valuable to add such builders? (for default and/or nogil)
Oh, I didn't know that :( If possible for me, "yes"
There was a problem hiding this comment.
If possible for me, "yes"
let me keep the existing builders as is (just marked as stable), and I'll look into adding refleak macos builders separately (probably marked "unstable" initially)
There was a problem hiding this comment.
I also believe the release manager considers the buildbot statuses when making release decisions, not GitHub Actions.
Yes, it's here: https://peps.python.org/pep-0101/#how-to-make-a-release
Check the stable buildbots.
Go to https://buildbot.python.org/all/#/release_status
Look at the buildbots for the release you’re making. Ignore any that are offline (or inform the community so they can be restarted). If what remains are (mostly) green buildbots, you’re good to go. If you have non-offline red buildbots, you may want to hold up the release until they are fixed. Review the problems and use your judgement, taking into account whether you are making an alpha, beta, or final release.
Although GitHub Actions is kind of implicitly included, because all PRs should be green before merging in the first place.
these builders have been very stable over the last few weeks.
with the official acceptance of PEP 703, I propose we promote these builders to a stable status.
note that the M1 builders was previously wrongly marked as "tier-1 unstable". according to PEP 11, Apple aarch64 is still considered tier-2, so until that changes, I moved the M1 NoGIL builder to "tier-2 stable".