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.
I already know that there will be a strike back: "oh no, you must
continue to support my architecture" and "their existing code should
stay and doesn't cost anything to maintain". Python is maintained by
volunteers, the majority is contributing in their free time, so people
are free to use their free time as they want. You cannot ask core
developers to support your favorite *legacy* platform/architecture if
they don't want to.
In short, I propose to move maintenance of the legacy platforms/archs
outside Python: people are free to continue support them as patches.
--
Concrete example: Christian Heimes proposed to drop support for 31-bit
s390 Linux:
https://bugs.python.org/issue43179
The lack of clear definition on how a platform is supported or not
confuses users who consider that their favorite platform/arch is
supported, whereas core developers don't want to support it since it
would be too much work.
In fact, the PEP 11 has clear and explicit rules:
https://www.python.org/dev/peps/pep-0011/#supporting-platforms
A platform is only considered as supported if the following two
conditions are met:
1) a core developer needs to volunteer to maintain platform-specific code
2) a stable buildbot must be provided
Last October, I proposed to drop Solaris support (bpo-42173). Jakub
Kulik stepped in and proposed some Solaris patches, so I abandoned my
idea. But I still don't see any running Solaris buildbot worker, and
there is still no core developer volunteer to maintain Solaris
support. It's unclear to me if Python has "best effort" support for
Solaris, of if Solaris is "not supported".
--
Over the years, Python was ported to tons of platforms and CPU
architectures. It didn't matter if the platform or the architecture
was commonly used or not. 30 years later, Python still has the code
for many legacy platforms and architectures. Some hardware is no
longer sold but kept alive by hobbyists, especially members of retro
computing groups.
Some Linux distributions like Gentoo and Debian are trying to support
most architectures which are supported by these hobbyist groups,
whereas some other distributions like Ubuntu are limited to a few
platforms. For example, Ubuntu 20.4.2 LTS server supports 4
architectures: x86-64, AArch64 (ARM), POWER and s390x. I guess that
the difference between Debian and Ubuntu is that Ubuntu is a Canonical
product, Canonical sells professional support and so cannot support
too many architectures. Each architecture support requires to build
all packages on it, tests the packages, have experts who fix issues
specific to this arch, etc.
--
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 :
"Tier 3 platforms are those which the Rust codebase has support for,
but which are not built or tested automatically, and may not work.
Official builds are not available."
https://doc.rust-lang.org/nightly/rustc/platform-support.html
Rust Tier 3 looks like our "Not supported" category.
Maybe we should have a better definition in the PEP 11 of our 3 support levels.
There is also a 4th category: platforms/archs which are really not
supported, like they legacy ones for which we removed the code :-)
Examples: BeOS, MacOS 9, platforms with no thread support, etc.
--
There is also a "Stable Buildbot" category used by the "Release
Status" web page:
https://buildbot.python.org/all/#/release_status
There is no clear rule why is a worker is added to that list or not.
For example, there are two FreeBSD workers which runs FreeBSD CURRENT:
the FreeBSD development branch. I don't think that it should be
declared as "stable".
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
_______________________________________________
Python-Dev mailing list -- python-...@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-...@python.org/message/F5BXISYP7RAINXUMYJSEYG7GCFRFAENF/
Code of Conduct: http://python.org/psf/codeofconduct/
