> On 4 Mar 2022, at 00:30, Brett Cannon <br...@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/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VDCMUXNSAMJGSHD6A235WBDHI7YETLVQ/ Code of Conduct: http://python.org/psf/codeofconduct/
