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