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.
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 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.
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.
FYI the tier support idea and the rough definitions above come from Rust:
https://doc.rust-lang.org/nightly/rustc/platform-support.html .
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.
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 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.
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.
FYI the tier support idea and the rough definitions above come from Rust:
https://doc.rust-lang.org/nightly/rustc/platform-support.html .