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