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 <[email protected]>,
@@ -14,109 +14,116 @@ 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.
+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.
 
-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:
+Support tiers
+=============
 
-- 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
+Platform support is broken down into *tiers*. Each tier comes with
+different requirements which lead to different promises being made
+about support.
 
-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.
+Tier 1
+------
 
-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.
+- `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 may be reverted immediately.
+- All core developers are responsible to keep these platforms,
+  and thus ``main``, working.
+- Promotion to this tier requires team consensus/SC approval.
+
+=================== =====
+Target Triple       Notes
+=================== =====
+i686-windows-msvc
+x86_64-windows-msvc
+x86_64-apple-darwin BSD libc, clang
+x86_64-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.
+- Promotion to this tier requires consensus/SC approval.
+
+====================== ========================== ============================================== ========
+Target Triple          Notes                      Buildbot                                       Contacts
+====================== ========================== ============================================== ========
+aarch64-apple-darwin   clang                      https://buildbot.python.org/all/#/builders/725 XXX
+aarch64-linux-gnu      glibc, gcc                 https://buildbot.python.org/all/#/builders/125 XXX
+
+                       glibc, clang               https://buildbot.python.org/all/#/builders/234 XXX
+aarch64-windows-msvc                              https://buildbot.python.org/all/#/builders/729 XXX
+powerpcle-linux-gnu    glibc, gcc                 https://buildbot.python.org/all/#/builders/90  XXX
+
+                       glibc, clang               https://buildbot.python.org/all/#/builders/435 XXX
+s390x-linux-gnu        glibc, gcc                 https://buildbot.python.org/all/#/builders/223 XXX
+
+                       glibc, clang               https://buildbot.python.org/all/#/builders/3   XXX
+x86_64-linux-gnu       glibc, clang               https://buildbot.python.org/all/#/builders/441 XXX
+x86_64-unknown-freebsd BSD libc, cc               https://buildbot.python.org/all/#/builders/172 XXX
+====================== ========================== ============================================== ========
+
+
+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 rejected
+or removed from the code base without a deprecation process if they
+cause a maintenance burden or obstruct general improvements.
 
-Re-supporting platforms
------------------------
+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.
 
-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.
+
+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 +137,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 +148,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 +161,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 +309,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.