PEP 11: define tiered platform support

pep-0011.txt

@@ -1,5 +1,5 @@
 PEP: 11
-Title: Removing support for little used platforms
+Title: CPython platform support
 Version: $Revision$
 Last-Modified: $Date$
 Author: Martin von Löwis <martin@v.loewis.de>,
@@ -14,109 +14,137 @@ Post-History: 18-Aug-2007,
 
 
 Abstract
---------
+========
 
 This PEP documents how an operating system (platform) becomes
-supported in CPython and documents past support.
+supported in CPython, what platforms are currently supported, and
+documents past support.
 
 
 Rationale
----------
+=========
 
 Over time, the CPython source code has collected various pieces of
 platform-specific code, which, at some point in time, was
-considered necessary to use Python on a specific platform.
+considered necessary to use CPython on a specific platform.
 Without access to this platform, it is not possible to determine
 whether this code is still needed.  As a result, this code may
-either break during Python's evolution, or it may become
+either break during CPython's evolution, or it may become
 unnecessary as the platforms evolve as well.
 
-The growing amount of these fragments poses the risk of
+Allowing these fragments to grow poses the risk of
 unmaintainability: without having experts for a large number of
 platforms, it is not possible to determine whether a certain
 change to the CPython source code will work on all supported
 platforms.
 
 To reduce this risk, this PEP specifies what is required for a
-platform to be considered supported by Python as well as providing a
-procedure to remove code for platforms with few or no Python
+platform to be considered supported by CPython as well as providing a
+procedure to remove code for platforms with few or no CPython
 users.
 
-Supporting platforms
---------------------
-
-Gaining official platform support requires two things. First, a core
-developer needs to volunteer to maintain platform-specific code. This
-core developer can either already be a member of the Python
-development team or be given contributor rights on the basis of
-maintaining platform support (it is at the discretion of the Python
-development team to decide if a person is ready to have such rights
-even if it is just for supporting a specific platform).
-
-Second, a stable buildbot must be provided [2]_. This guarantees that
-platform support will not be accidentally broken by a Python core
-developer who does not have personal access to the platform. For a
-buildbot to be considered stable it requires that the machine be
-reliably up and functioning (but it is up to the Python core
-developers to decide whether to promote a buildbot to being
-considered stable).
-
-This policy does not disqualify supporting other platforms
-indirectly. Patches which are not platform-specific but still done to
-add platform support will be considered for inclusion. For example,
-if platform-independent changes were necessary in the configure
-script which were motivated to support a specific platform that could
-be accepted. Patches which add platform-specific code such as the
-name of a specific platform to the configure script will generally
-not be accepted without the platform having official support.
-
-CPU architecture and compiler support are viewed in a similar manner
-as platforms. For example, to consider the ARM architecture supported
-a buildbot running on ARM would be required along with support from
-the Python development team. In general it is not required to have
-a CPU architecture run under every possible platform in order to be
-considered supported.
-
-Unsupporting platforms
-----------------------
-
-If a certain platform that currently has special code in CPython is
-deemed to be without enough Python users or lacks proper support from
-the Python development team and/or a buildbot, a note must be posted
-in this PEP that this platform is no longer actively supported.  This
-note must include:
-
-- the name of the system
-- the first release number that does not support this platform
-  anymore, and
-- the first release where the historical support code is actively
-  removed
-
-In some cases, it is not possible to identify the specific list of
-systems for which some code is used (e.g. when autoconf tests for
-absence of some feature which is considered present on all
-supported systems).  In this case, the name will give the precise
-condition (usually a preprocessor symbol) that will become
-unsupported.
-
-At the same time, the CPython source code must be changed to
-produce a build-time error if somebody tries to install Python on
-this platform.  On platforms using autoconf, configure must fail.
-This gives potential users of the platform a chance to step
-forward and offer maintenance.
-
-
-Re-supporting platforms
------------------------
-
-If a user of a platform wants to see this platform supported
-again, they may volunteer to maintain the platform support.  Such an
-offer must be recorded in the PEP, and the user can submit patches
-to remove the build-time errors, and perform any other maintenance
-work for the platform.
+This PEP also lists what plaforms *are* supported by the CPython
+interpreter. This lets people know what platforms are directly
+supported by the CPython development team.
+
+
+Support tiers
+=============
+
+Platform support is broken down into *tiers*. Each tier comes with
+different requirements which lead to different promises being made
+about support.
+
+To be promoted to a tier, steering council support is required and is
+expected to be driven by team consensus. Demotion to a lower tier
+occurs when the requirements of the current tier are no longer met for
+a platform for an extended period of time based on the judgment of
+the release manager or steering council. For platforms which no longer
+meet the requirements of any tier by b1 of a new feature release, an
+announcement will be made to warn the community of the pending removal
+of support for the platform (e.g. in the b1 announcement). If the
+platform is not brought into line for at least one of the tiers by the
+first release candidate, it will be listed as unsupported in this PEP.
+
+Tier 1
+------
+
+- `CI failures <https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>`__ block releases.
+- Changes which would break the ``main`` branch are not allowed to be merged;
+  any breakage should be fixed or reverted immediately.
+- All core developers are responsible to keep ``main``, and thus these
+  platforms, working.
+- Failures on these platforms **block a release**.
+
+======================== =====
+Target Triple            Notes
+======================== =====
+i686-pc-windows-msvc
+x86_64-pc-windows-msvc
+x86_64-apple-darwin      BSD libc, clang
+x86_64-unknown-linux-gnu glibc, gcc
+======================== =====
+
+
+Tier 2
+------
+
+- Must have a reliable buildbot.
+- At least **two** core developers are signed up to support the platform.
+- Changes which break any of these platforms are to be **fixed or
+  reverted within 24 hours**.
+- Failures on these platforms **block a release**.
+
+=========================== ========================== ============================================== ========
+Target Triple               Notes                      Buildbot                                       Contacts
+=========================== ========================== ============================================== ========
+aarch64-apple-darwin        clang                      https://buildbot.python.org/all/#/builders/725 Ned Deily, Ronald Oussoren, Dong-he Na
+aarch64-unknown-linux-gnu   glibc, gcc                 https://buildbot.python.org/all/#/builders/125 Petr Viktorin, Victor Stinner
+
+                            glibc, clang               https://buildbot.python.org/all/#/builders/234 Victor Stinner, Gregory P. Smith
+powerpcle-unknown-linux-gnu glibc, gcc                 https://buildbot.python.org/all/#/builders/90  Petr Viktorin, Victor Stinner
+x86_64-unknownlinux-gnu     glibc, clang               https://buildbot.python.org/all/#/builders/441 Victor Stinner, Gregory P. Smith
+=========================== ========================== ============================================== ========
+
+
+Tier 3
+------
+
+- Must have a reliable buildbot.
+- At least **one** core developer is signed up to support the platform.
+- No response SLA to failures.
+- Failures on these platforms do **not** block a release.
+
+============================== =========================== ============================================== ========
+Target Triple                  Notes                       Buildbot                                       Contacts
+============================== =========================== ============================================== ========
+aarch64-pc-windows-msvc                                    https://buildbot.python.org/all/#/builders/729 Steve Dower
+powerpcle-unknown-linux-gnu    glibc, clang                https://buildbot.python.org/all/#/builders/435 Victor Stinner
+x86_64-unknown-freebsd         BSD libc, clang             https://buildbot.python.org/all/#/builders/172 Victor Stinner
+armv7l-unknown-linux-gnueabihf Raspberry Pi OS, glibc, gcc https://buildbot.python.org/all/#/builders/424 Gregory P. Smith
+============================== =========================== ============================================== ========
+
+
+All other platforms
+-------------------
+
+Support for a platform may be partial within the code base, such as
+from active development around platform support or accidentally.
+Code changes to platforms not listed in the above tiers may be rejected
+or removed from the code base without a deprecation process if they
+cause a maintenance burden or obstruct general improvements.
+
+Platforms not listed here may be supported by the wider Python
+community in some way. If your desired platform is not listed above,
+please perform a search online to see if someone is already providing
+support in some form.
+
+
+Notes
+-----
 
 Microsoft Windows
------------------
+'''''''''''''''''
 
 Microsoft has established a policy called product support lifecycle
 [1]_. Each product's lifecycle has a mainstream support phase, where
@@ -130,9 +158,6 @@ phase is not yet expired. Subsequent bug fix releases will support
 the same Windows releases as the original feature release (even if
 the extended support phase has ended).
 
-Because of this policy, no further Windows releases need to be listed
-in this PEP.
-
 Each feature release is built by a specific version of Microsoft
 Visual Studio. That version should have mainstream support when the
 release is made. Developers of extension modules will generally need
@@ -144,8 +169,9 @@ patches will be accepted. Such build files will be removed from the
 source tree 3 years after the extended support for the compiler has
 ended (but continue to remain available in revision control).
 
+
 Legacy C Locale
----------------
+'''''''''''''''
 
 Starting with CPython 3.7.0, \*nix platforms are expected to provide
 at least one of ``C.UTF-8`` (full locale), ``C.utf8`` (full locale) or
@@ -156,8 +182,36 @@ Any Unicode-related integration problems that occur only in the legacy ``C``
 locale and cannot be reproduced in an appropriately configured non-ASCII
 locale will be closed as "won't fix".
 
+
+Unsupporting platforms
+======================
+
+If a platform drops out of tiered support, a note must be posted
+in this PEP that the platform is no longer actively supported.  This
+note must include:
+
+- the name of the system
+- the first release number that does not support this platform
+  anymore, and
+- the first release where the historical support code is actively
+  removed
+
+In some cases, it is not possible to identify the specific list of
+systems for which some code is used (e.g. when autoconf tests for
+absence of some feature which is considered present on all
+supported systems).  In this case, the name will give the precise
+condition (usually a preprocessor symbol) that will become
+unsupported.
+
+At the same time, the CPython source code must be changed to
+produce a build-time error if somebody tries to install CPython on
+this platform.  On platforms using autoconf, configure must fail.
+This gives potential users of the platform a chance to step
+forward and offer maintenance.
+
+
 No-longer-supported platforms
------------------------------
+=============================
 
 * | Name:             MS-DOS, MS-Windows 3.x
   | Unsupported in:   Python 2.0
@@ -276,15 +330,15 @@ No-longer-supported platforms
   | Code removed in:  Python 3.7
 
 References
-----------
+==========
 
 .. [1] http://support.microsoft.com/lifecycle/
-.. [2] http://buildbot.python.org/3.x.stable/
 
 Copyright
----------
+=========
 
-This document has been placed in the public domain.
+This document is placed in the public domain or under the
+CC0-1.0-Universal license, whichever is more permissive.