From: Aisha Tammy <gentoo.dev@aisha.cc>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Fwd: [Python-Dev] Move support of legacy platforms/architectures outside Python
Date: Sun, 21 Feb 2021 08:28:40 -0500 [thread overview]
Message-ID: <34cde122-41ec-db44-4057-42634d2890d8@aisha.cc> (raw)
In-Reply-To: <3a6d1809b74b4320611cd36016e6b258f4458d05.camel@gentoo.org>
On 2/21/21 8:01 AM, Michał Górny wrote:
> Hi,
>
> FYI, a few member of Python upstream are continuing their crusade
> against minor architectures not supported by Rust. This time, they're
> discussing actively removing support for platforms they don't officially
> support, and requiring people to maintain external patches forever.
>
ggwp was fun
> -------- Forwarded Message --------
> From: Victor Stinner <vstinner@python.org>
> To: Python Dev <Python-Dev@python.org>
> Subject: [Python-Dev] Move support of legacy platforms/architectures
> outside Python
> Date: Sun, 21 Feb 2021 13:13:45 +0100
>
>> 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-dev@python.org
>> To unsubscribe send an email to python-dev-leave@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/F5BXISYP7RAINXUMYJSEYG7GCFRFAENF/
>> Code of Conduct: http://python.org/psf/codeofconduct/
next prev parent reply other threads:[~2021-02-21 13:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABqyc3zVU0rLzcPA_vwdnDp3oKLP0HnMuDN6VNPwWpfY-X38hQ@mail.gmail.com>
2021-02-21 13:01 ` [gentoo-dev] Fwd: [Python-Dev] Move support of legacy platforms/architectures outside Python Michał Górny
2021-02-21 13:28 ` Aisha Tammy [this message]
2021-02-22 1:32 ` Joshua Kinard
2021-02-22 8:30 ` Michał Górny
2021-02-23 6:16 ` Alec Warner
2021-02-23 8:11 ` Michał Górny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=34cde122-41ec-db44-4057-42634d2890d8@aisha.cc \
--to=gentoo.dev@aisha.cc \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox