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 <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 <http://python.org/> (macOS 10.9 or later, both x86_64 and arm64). AFAIK support for macOS 10.9 in the python.org <http://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? Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/