On Sun, Feb 21, 2021 at 12:03 PM Michał Górny <mgo...@gentoo.org> wrote:
> 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? > > 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. -gps > -- > 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/ >
_______________________________________________ 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/25FRS4NW6RLSNFQK46UUGJPO2DWIOHHK/ Code of Conduct: http://python.org/psf/codeofconduct/
