On Sun, Feb 21, 2021 at 12:03 PM Michał Górny firstname.lastname@example.org wrote:
On Sun, 2021-02-21 at 13:35 +0100, Christian Heimes wrote:
On 21/02/2021 13.13, Victor Stinner wrote:
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 :
(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
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:
- 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?
Definitely start with this. This level of effort to maintain the minor platform support in-tree may be able to keep an otherwise neglected minor platform in second tier non-release-blocker best effort status. Having a buildbot, at least provides visibility, and sometimes PR authors will be sympathetic to easy edits that keep something working that way (no guarantee).
The main thing from a project maintenance perspective is for platforms to not become a burden to other code maintainers. PRs need to be reviewed. Every #if/#endif in code is a cognitive burden. So being a minor platform can come with unexpected breakages that need fixing due to other changes made in the codebase that did not pay attention to the platform. As we cannot expect everyone working on code to care about anything beyond the tier-1 fully supported platforms, buildbot or not.
Example: I consider many of the BSDs and the Solaris derivatives to be in this state. (non specific here, i don't even know which ones we claim are supported or not without going and reading whatever policy docs we might or might not have today - Victor alludes to this state of the world). We tend to accept patches when someone offers them. Occasionally we have a core dev who actually runs one of them. But most of us don't go out of the way ourselves to try and keep changes we make working there. We expect interested parties to jump in when something isn't working right. And will generally do related PR reviews/merges if they're not burdensome.
An example of the above happening recently is VxWorks support via https://bugs.python.org/issue31904.
-- Best regards, Michał Górny
Python-Dev mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://email@example.com/message/FI2D6VQQ... Code of Conduct: http://python.org/psf/codeofconduct/