On 4 Mar 2022, at 00:30, Brett Cannon <brett@python.org> wrote:

Do we officially support NetBSD? Do you know how to find out if we do? You might think to look at https://www.python.org/dev/peps/pep-0011/#supporting-platforms , but that just loosely defines the criteria and it still doesn't list the actual platforms we support. (BTW I don't know if we do officially support NetBSD, hence this email.)

I think we should clarify this sort of thing and be a bit more upfront with the level of support we expect/provide for a platform. As such, I want to restructure PEP 11 to list the platforms we support, not just list the platforms we stopped supporting. To do this I want define 3 different tiers that outline what our support requirements and promises are for platforms.

Tier 1 is the stuff we run CI against: latest Windows, latest macOS, Linux w/ the latest glibc (I don't know of a better way to define Linux support as I don't know if a per-distro list is the right abstraction). These are platforms we won't even let code be committed for if they would break; they block releases if they don't work. These platforms we all implicitly promise to support.

Tier 2 is the platforms we would revert a change within 24 hours if they broke: latest FeeBSD, older Windows, older macOS, Linux w/ older glibc.This is historically the "stable buildbot plus a core dev" group of platforms. The change I would like to see is two core devs (in case one is on vacation), and a policy as to how a platform ends up here (e.g. SC must okay it based on consensus of everyone). The stable buildbot would still be needed to know if a release is blocked as we would hold a release up if they were red. The platform and the core devs supporting these platforms would be listed in PEP 11.

What’s the difference between Tier 1 and 2 other than that PRs are checked with tier 1 platforms before committing and with tier 2 afterwards?

In particular, tier 1 contains windows server and not desktop (even though I expect that those are compatible as far as our use is concerned), and does not contain the macOS versions that we actually support in the installers on python.org (macOS 10.9 or later, both x86_64 and arm64). AFAIK support for macOS 10.9 in the python.org installers is now primarily, if not only, tested by Ned. That could, and probably should, be automated but that’s a significant amount of work.

[…]

I don't know if we want to bother listing CPU architectures since we are a pure C project which makes CPU architecture less of a thing, but I'm personally open to the idea of CPU architectures being a part of the platform definition.

CTypes is hardware specific, although through libiff. There’s also intermittent discussions about support for ancient hardware platforms. Would we block a release when (for example) support for Linux on sparc32 is broken?