On 04. 03. 22 0:30, Brett Cannon 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.

While you're at it: consider moving the lists to the devguide, so the
PEP would only contain the general process & criteria.

> 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.

Do we need two core devs to revert changes?

What are the duties of someone listed for a platform, anyway?

> Tier 3 are platforms we accept PRs for to keep working, but they won't
> block a release. At least one core dev must be listed to be in charge of
> PRs that affect the platform. A buildbot would be nice but not required.
> I'm thinking either historical platforms we support or something like
> Emscripten that's working towards being a tier 2 platform. I'm not sure
> if we want to have explicit approval to be in this tier beyond the
> outlined requirements, but obviously if a core dev isn't keeping up with
> PRs then the platform will be dropped.
>
> All other platforms we do not directly support in the repository and it
> is up to the community to keep functioning. We can obviously keep
> accepting general patches to up compatibility, but platform-specific
> patches for anything outside of these tiers wouldn't. No issue if
> someone provides a buildbot for their own benefit, but these buildbots
> would never hold anything up.
>
> When a Python version hits b1, then that platform is considered
> supported for that version as long as the requirements outlined above
> continue to be met. Once the Python version hits EOL then like anything,
> support ends no matter what. We could capture the supported platforms
> for a version in the release schedule PEP if people want >
> I would expect appropriate labels being added to the builders listed at
> https://buildbot.python.org/all/#/builders
> <https://buildbot.python.org/all/#/builders> to signify which platforms
> we block releases for (e.g. `tier-1,`, `tier-2`, or `release-blocker` as
> a generic label).
>
> I would expect PEP 11 to list the appropriate C symbol that's set for
> that platform, e.g. __linux__.
>
> 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.

IMO it would be good to be explicit wrt. testing and support. There's a
lot of arch/compiler assumptions still hidden in the codebase.

> I don't think we should cover C compilers here as that's covered by PEP
> 7. Otherwise PEP 7 should only list C versions/features and PEP 11 lists
> compilers and their versions.

I think it would be good to move that here. It's a “platform support”
matter, not “code style”.

> FYI the tier support idea and the rough definitions above come from
> Rust: https://doc.rust-lang.org/nightly/rustc/platform-support.html
> <https://doc.rust-lang.org/nightly/rustc/platform-support.html> .
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/QXH2ZTE2DZOGVTZYW2TVQXXDF3XVYV7D/
Code of Conduct: http://python.org/psf/codeofconduct/