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-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/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-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/QXH2ZTE2DZOGVTZYW2TVQXXDF3XVYV7D/
Code of Conduct: http://python.org/psf/codeofconduct/
