Thanks to Petr, and Victor, the platforms that are still looking for a total of two maintainers over at are:
  1. arch64-apple-darwin clang
  2. aarch64-linux-gnu glibc, clang (Victor is already listed)
  3. aarch64-windows-msvc
  4. powerpcle-linux-gnu glibc, clang
  5. s390x-linux-gnu glibc, gcc
  6. s390x-linux-gnu glibc, clang
  7. x86_64-linux-gnu glibc, clang (Victor is already listed)
  8. x86_64-unknown-freebsd BSD libc, cc (Victor is already listed)

On Thu, Mar 24, 2022 at 12:37 PM Brett Cannon <> wrote:
Based on the positive feedback that I've gotten on this and the only other suggestion was maybe bringing back tier 3 to represent, "being actively worked on" support (which i think we can add later if we feel it's worth it), I'm ready to ask folks to please start sending review suggestions on to add yourself as supporting a platform (see if you don't know what I mean by "review suggestion").

I believe at least Victor is currently out at the moment, so I'm not planning to rush this out and start removing platforms that lack two people and merging this PR, but I also don't want to put it off either. As a reminder, the platforms looking for declared support as a tier 2 platform are:

  1. arch64-apple-darwin clang
  2. aarch64-linux-gnu glibc, gcc
  3. aarch64-linux-gnu glibc, clang
  4. aarch64-windows-msvc
  5. powerpcle-linux-gnu glibc, gcc
  6. powerpcle-linux-gnu glibc, clang
  7. s390x-linux-gnu glibc, gcc
  8. s390x-linux-gnu glibc, clang
  9. x86_64-linux-gnu glibc, clang
  10. x86_64-unknown-freebsd BSD libc, cc

Tier 1 is taken care of:
  1. i686-windows-msvc
  2. x86_64-windows-msvc
  3. x86_64-apple-darwin BSD libc, clang
  4. x86_64-linux-gnu glibc, gcc

On Thu, Mar 17, 2022 at 5:56 PM Brett Cannon <> wrote:
After considering everyone's feedback, here are my proposed explanations for the tiers.

Tier 1

- `CI failures <>`__ 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.

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.

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.

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.

I have a draft PR up at which can be previewed at (makes reading the table much easier). I made the platforms list the platform triple, libc, and compiler **without** version details.

Once I have buy-in for the above I will explicitly ask folks to send review comments to that PR to add themselves to the platforms they are willing to support, and then drop any which lack two core developers (warnings to the Fedora/RH folks: most of those platforms are listed are using Fedora buildbots, so it might be up  to you 😉). I did drop powerpc-linux-gnu from the list as that buildbot has not successfully built in quite some time (powerpcle seems fine).

On Mon, Mar 14, 2022 at 5:35 PM Gregory P. Smith <> wrote:

On Mon, Mar 14, 2022 at 11:43 AM Marc-Andre Lemburg <> wrote:
On 14.03.2022 19:34, Brett Cannon wrote:
> Greg proposed something like "Code changes to support platforms beyond tier1 or
> tier2 may be rejected, broken, or removed from the CPython codebase without
> notice if they cause a maintenance burden for tier1&2 or obstruct general
> improvements." and drop the concept of tier 3. Does that work for you?

Almost :-) I don't understand the "without notice". I guess Greg
meant "without deprecation process". Removal of support code should
be discussed on a ticket and then listed in PEP 11 and
mentioned in the NEWS file, as usual.

I guess I was trying to convey that we may not even have a way to know that we're breaking something on a non-tier1/2 platform anyways so "without notice" was just me trying to set people's expectations.  We don't go out of our way to _try_ and break things most of the time.  "without a deprecation process" is also reasonable wording.  Feel free to adopt those words.

Ideally we try to have discussion somewhere relevant when we _know_ we'd intentionally be removing support for something (for example of why: See the debacle that happened when dropping Solaris support was proposed).


Marc-Andre Lemburg

Professional Python Services directly from the Experts (#1, Mar 14 2022)
>>> Python Projects, Coaching and Support ...
>>> Python Product Development ...

::: We implement business ideas - efficiently in both time and costs ::: Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

python-committers mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: