> That's not really the question. The question is whether an upstream project should prevent downstreams from using unsupported target configurations and I think the answer to that question is no.

We are not (actively) prevent unsupported target. We are merely removing unused code that we cannot test. Downstream is free to re-apply or maintain additional patches to enable platforms that we don't support. The rules for platform support are explained in PEP 11.

> Python is free software (as opposed to just open source software) and one of the key features of free software is that you don't tell your users how they use your software.

Free software doesn't mean free labor. Upstream is free to choose how we spend our time on the project or which patches we accept. For platform support we have (IMHO) reasonable rules for code: Python must compile, work, and pass a sufficient set of its test suite.

While "Python" software is free, the trademark, logo, and rights to the name "Python" are owned by the PSF. The trademark rules are also reasonable. On very few occasions the PSF has asked developers to choose a different name to avoid confusion. For example we asked the developer of a Python 2.8 fork to rename. The fork is now known a Tauthon. Platform compatibility patches are fine.

I see three ways to resolve the dispute:

1) You provide and support CI for s390, we keep the platform triplet. I would be even fine with an unstable buildbot or external CI that builds and runs out test suite regularly.
2) We remove the platform, you maintain downstream patches. The patch in GH-24534 is small and trivial.
3) You contact the Python Steering Council and request a decision. The SC is our elect government and makes final decisions.

I'm going to hold off and delay PR 24534 for at least two weeks to give you time to work on (1) or (3).