| 1 |
On 2/21/21 8:01 AM, Michał Górny wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> FYI, a few member of Python upstream are continuing their crusade |
| 5 |
> against minor architectures not supported by Rust. This time, they're |
| 6 |
> discussing actively removing support for platforms they don't officially |
| 7 |
> support, and requiring people to maintain external patches forever. |
| 8 |
> |
| 9 |
ggwp was fun |
| 10 |
|
| 11 |
> -------- Forwarded Message -------- |
| 12 |
> From: Victor Stinner <vstinner@××××××.org> |
| 13 |
> To: Python Dev <Python-Dev@××××××.org> |
| 14 |
> Subject: [Python-Dev] Move support of legacy platforms/architectures |
| 15 |
> outside Python |
| 16 |
> Date: Sun, 21 Feb 2021 13:13:45 +0100 |
| 17 |
> |
| 18 |
>> Hi, |
| 19 |
>> |
| 20 |
>> I propose to actively remove support for *legacy* platforms and |
| 21 |
>> architectures which are not supported by Python according to PEP 11 |
| 22 |
>> rules: hardware no longer sold and end-of-life operating systems. The |
| 23 |
>> removal should be discussed on a case by case basis, but I would like |
| 24 |
>> to get an agreement on the overall idea first. Hobbyists wanting to |
| 25 |
>> support these platforms/archs can continue to support them with |
| 26 |
>> patches maintained outside Python. For example, I consider that the |
| 27 |
>> 16-bit m68k architecture is legacy, whereas the OpenBSD platform is |
| 28 |
>> still actively maintained. |
| 29 |
>> |
| 30 |
>> I already know that there will be a strike back: "oh no, you must |
| 31 |
>> continue to support my architecture" and "their existing code should |
| 32 |
>> stay and doesn't cost anything to maintain". Python is maintained by |
| 33 |
>> volunteers, the majority is contributing in their free time, so people |
| 34 |
>> are free to use their free time as they want. You cannot ask core |
| 35 |
>> developers to support your favorite *legacy* platform/architecture if |
| 36 |
>> they don't want to. |
| 37 |
>> |
| 38 |
>> In short, I propose to move maintenance of the legacy platforms/archs |
| 39 |
>> outside Python: people are free to continue support them as patches. |
| 40 |
>> |
| 41 |
>> -- |
| 42 |
>> |
| 43 |
>> Concrete example: Christian Heimes proposed to drop support for 31-bit |
| 44 |
>> s390 Linux: |
| 45 |
>> https://bugs.python.org/issue43179 |
| 46 |
>> |
| 47 |
>> The lack of clear definition on how a platform is supported or not |
| 48 |
>> confuses users who consider that their favorite platform/arch is |
| 49 |
>> supported, whereas core developers don't want to support it since it |
| 50 |
>> would be too much work. |
| 51 |
>> |
| 52 |
>> In fact, the PEP 11 has clear and explicit rules: |
| 53 |
>> https://www.python.org/dev/peps/pep-0011/#supporting-platforms |
| 54 |
>> |
| 55 |
>> A platform is only considered as supported if the following two |
| 56 |
>> conditions are met: |
| 57 |
>> |
| 58 |
>> 1) a core developer needs to volunteer to maintain platform-specific code |
| 59 |
>> 2) a stable buildbot must be provided |
| 60 |
>> |
| 61 |
>> Last October, I proposed to drop Solaris support (bpo-42173). Jakub |
| 62 |
>> Kulik stepped in and proposed some Solaris patches, so I abandoned my |
| 63 |
>> idea. But I still don't see any running Solaris buildbot worker, and |
| 64 |
>> there is still no core developer volunteer to maintain Solaris |
| 65 |
>> support. It's unclear to me if Python has "best effort" support for |
| 66 |
>> Solaris, of if Solaris is "not supported". |
| 67 |
>> |
| 68 |
>> -- |
| 69 |
>> |
| 70 |
>> Over the years, Python was ported to tons of platforms and CPU |
| 71 |
>> architectures. It didn't matter if the platform or the architecture |
| 72 |
>> was commonly used or not. 30 years later, Python still has the code |
| 73 |
>> for many legacy platforms and architectures. Some hardware is no |
| 74 |
>> longer sold but kept alive by hobbyists, especially members of retro |
| 75 |
>> computing groups. |
| 76 |
>> |
| 77 |
>> Some Linux distributions like Gentoo and Debian are trying to support |
| 78 |
>> most architectures which are supported by these hobbyist groups, |
| 79 |
>> whereas some other distributions like Ubuntu are limited to a few |
| 80 |
>> platforms. For example, Ubuntu 20.4.2 LTS server supports 4 |
| 81 |
>> architectures: x86-64, AArch64 (ARM), POWER and s390x. I guess that |
| 82 |
>> the difference between Debian and Ubuntu is that Ubuntu is a Canonical |
| 83 |
>> product, Canonical sells professional support and so cannot support |
| 84 |
>> too many architectures. Each architecture support requires to build |
| 85 |
>> all packages on it, tests the packages, have experts who fix issues |
| 86 |
>> specific to this arch, etc. |
| 87 |
>> |
| 88 |
>> -- |
| 89 |
>> |
| 90 |
>> Python has different kinds of platform and architecture supports. In |
| 91 |
>> practice, I would say that we have: |
| 92 |
>> |
| 93 |
>> * (1) Fully supported. Platform/architecture used by core developers |
| 94 |
>> and have at least one working buildbot worker: fully supported. Since |
| 95 |
>> core developers want to use Python on their machine, they fix issues |
| 96 |
>> as soon as they notice them. Examples: x86-64 on Linux, Windows and |
| 97 |
>> macOS. |
| 98 |
>> |
| 99 |
>> * (2) Best effort. Platform/architecture which has a buildbot worker |
| 100 |
>> usually not used by core developers. Regressions (buildbot failures) |
| 101 |
>> are reported to bugs.python.org, if someone investigates and provides |
| 102 |
>> a fix, the fix is merged. But there is usually no "proactive" work to |
| 103 |
>> ensure that Python works "perfectly" on these platforms. Example: |
| 104 |
>> FreeBSD/x86-64. |
| 105 |
>> |
| 106 |
>> * (3) Not (officially) supported. We enter the blurry grey area. There |
| 107 |
>> is no buildbot worker, no core dev use it, but Python contains code |
| 108 |
>> specific to these platforms/architectures. Example: 16-bit m68k and |
| 109 |
>> 31-bit s390 architectures, OpenBSD. |
| 110 |
>> |
| 111 |
>> The Rust programming language has 3 categories of Platform Support, |
| 112 |
>> the last one is : |
| 113 |
>> |
| 114 |
>> "Tier 3 platforms are those which the Rust codebase has support for, |
| 115 |
>> but which are not built or tested automatically, and may not work. |
| 116 |
>> Official builds are not available." |
| 117 |
>> https://doc.rust-lang.org/nightly/rustc/platform-support.html |
| 118 |
>> |
| 119 |
>> Rust Tier 3 looks like our "Not supported" category. |
| 120 |
>> |
| 121 |
>> Maybe we should have a better definition in the PEP 11 of our 3 support levels. |
| 122 |
>> |
| 123 |
>> There is also a 4th category: platforms/archs which are really not |
| 124 |
>> supported, like they legacy ones for which we removed the code :-) |
| 125 |
>> Examples: BeOS, MacOS 9, platforms with no thread support, etc. |
| 126 |
>> |
| 127 |
>> -- |
| 128 |
>> |
| 129 |
>> There is also a "Stable Buildbot" category used by the "Release |
| 130 |
>> Status" web page: |
| 131 |
>> https://buildbot.python.org/all/#/release_status |
| 132 |
>> |
| 133 |
>> There is no clear rule why is a worker is added to that list or not. |
| 134 |
>> For example, there are two FreeBSD workers which runs FreeBSD CURRENT: |
| 135 |
>> the FreeBSD development branch. I don't think that it should be |
| 136 |
>> declared as "stable". |
| 137 |
>> |
| 138 |
>> Victor |
| 139 |
>> -- |
| 140 |
>> Night gathers, and now my watch begins. It shall not end until my death. |
| 141 |
>> _______________________________________________ |
| 142 |
>> Python-Dev mailing list -- python-dev@××××××.org |
| 143 |
>> To unsubscribe send an email to python-dev-leave@××××××.org |
| 144 |
>> https://mail.python.org/mailman3/lists/python-dev.python.org/ |
| 145 |
>> Message archived at https://mail.python.org/archives/list/python-dev@××××××.org/message/F5BXISYP7RAINXUMYJSEYG7GCFRFAENF/ |
| 146 |
>> Code of Conduct: http://python.org/psf/codeofconduct/ |
Archives