On Fri, Mar 4, 2022 at 1:32 AM Ronald Oussoren <ronaldousso...@mac.com> wrote:
> > > 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 , 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? > Everyone on the core team supports tier 1, while for tier 2 there's only those who specifically volunteer to support it. > > 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. > So macOS 10.9 would be tier 3. There's nothing wrong with that, just we obviously don't know when it fails now anyway, so it technically only holds up a release so much as Ned as RM for macOS builds can choose to. > > > […] > > > > 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? > If it's tier 2 or higher, yes. -Brett > > > 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/PQQSPHK6HSOGYCFJ6NIVMJJISSWNYU3Z/ Code of Conduct: http://python.org/psf/codeofconduct/
