On Sun, 2021-02-21 at 13:35 +0100, Christian Heimes wrote: > On 21/02/2021 13.13, Victor Stinner wrote: > > Hi, > > > > I propose to actively remove support for *legacy* platforms and > > architectures which are not supported by Python according to PEP 11 > > rules: hardware no longer sold and end-of-life operating systems. The > > removal should be discussed on a case by case basis, but I would like > > to get an agreement on the overall idea first. Hobbyists wanting to > > support these platforms/archs can continue to support them with > > patches maintained outside Python. For example, I consider that the > > 16-bit m68k architecture is legacy, whereas the OpenBSD platform is > > still actively maintained. > [...] > > Python has different kinds of platform and architecture supports. In > > practice, I would say that we have: > > > > * (1) Fully supported. Platform/architecture used by core developers > > and have at least one working buildbot worker: fully supported. Since > > core developers want to use Python on their machine, they fix issues > > as soon as they notice them. Examples: x86-64 on Linux, Windows and > > macOS. > > > > * (2) Best effort. Platform/architecture which has a buildbot worker > > usually not used by core developers. Regressions (buildbot failures) > > are reported to bugs.python.org, if someone investigates and provides > > a fix, the fix is merged. But there is usually no "proactive" work to > > ensure that Python works "perfectly" on these platforms. Example: > > FreeBSD/x86-64. > > > > * (3) Not (officially) supported. We enter the blurry grey area. There > > is no buildbot worker, no core dev use it, but Python contains code > > specific to these platforms/architectures. Example: 16-bit m68k and > > 31-bit s390 architectures, OpenBSD. > > > > The Rust programming language has 3 categories of Platform Support, > > the last one is : > > Thanks Victor! > > (short reply, I'm heading out) > > I'm +1 in general for your proposal. I also like the idea to adopt > Rust's platform support definition. > > For 3.10 I propose to add a configure option to guard builds on > unsupported / unstable platforms. My draft PR > https://github.com/python/cpython/pull/24610/commits/f8d2d56757a9cec7ae4dc721047336eaba097125 > implements a checker for unsupported platforms and adds a > --enable-unstable-platforms flag. Configuration on unsupported platforms > fails unless users explicitly opt-in. > > The checker serves two purposes: > > 1) It gives users an opportunity to provide full PEP 11 support > (buildbot, engineering time) for a platform.
Does that mean that if someone offers to run the build bot for a minor platform and do the necessary maintenance to keep it working, they will be able to stay? How much maintenance is actually expected, i.e. is it sufficient to maintain CPython in a 'good enough' working state to resolve major bugs blocking real usage on these platforms? -- Best regards, Michał Górny _______________________________________________ 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/FI2D6VQQ4DBBCTYOWYMZBTSU2VWCQP34/ Code of Conduct: http://python.org/psf/codeofconduct/
