[gentoo-dev] Fwd: [Python-Dev] Move support of legacy platforms/architectures outside Python

[gentoo-dev] Fwd: [Python-Dev] Move support of legacy platforms/architectures outside Python

[Michał Górny]

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.


-------- 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/

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Fwd: [Python-Dev] Move support of legacy platforms/architectures outside Python

[Aisha Tammy]

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/

Re: [gentoo-dev] Fwd: [Python-Dev] Move support of legacy platforms/architectures outside Python

[Joshua Kinard]

On 2/21/2021 08:01, 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.

In case I missed something, what is the intersection here between Rust and
Python?  Is it just the Python devs taking a page out of Rust's guidebook on
platform/arch support, or is there some change coming down the road, like
where Python will be re-written in Rust?


> -------- 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".

Just commentary here, but likely they'll need to go and poke Oracle for
proper Solaris support.  I wonder, though, whether the illumos community
could keep this alive, unless illumos has drifted too far apart from Solaris
11.4 and becomes its own build tuple?


>> --
>>
>> 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.

:: glances around nervously and hides in a bush w/ his old SGI machines ::


>> 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.

Someone from Python should probably look up the port maintainer on FreeBSD
here and poke them about this.  FreeBSD/x86_64 is a Tier 1 architecture, so
it gets attention.  Likely the port maintainer just hasn't fed any support
patches back upstream.


>> * (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.

For BeOS, probably a question for the Haiku community on what, if any,
patches they are maintaining to support Python there.  IMHO, BeOS support
can probably be dropped and replaced with support for Haiku.  That project
is coming along rather nicely.


>>
>> --
>>
>> 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/
> 


-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Fwd: [Python-Dev] Move support of legacy platforms/architectures outside Python

[Michał Górny]

On Sun, 2021-02-21 at 20:32 -0500, Joshua Kinard wrote:
> On 2/21/2021 08:01, 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.
> 
> In case I missed something, what is the intersection here between Rust and
> Python?  Is it just the Python devs taking a page out of Rust's guidebook on
> platform/arch support, or is there some change coming down the road, like
> where Python will be re-written in Rust?

It's the context/timing.  Cryptography starts being rewritten in Rust. 
I report a bug that this breaks platforms not supported by Rust [1]. 
Suddenly a few core Python developers appear and applaud the effort,
indicating that Python does not support these arches.

In middle of this, one of the Python devs proposes removing s390
support.  The patch [2] does not remove any real code that could burden
developers -- it just demolishes some places to break the support.
The request receives negative feedback.

So now we have suddenly the crusade against all 'unsupported'
architectures, to justify the crusade.

I don't know whether Python will actually be rewritten in Rust or start
depending on Rust packages but it's not impossible.  However, it's
pretty clear that the whole discussion was triggered by the Rust rewrite
of cryptography.

As for your other comments, I can't really comment on them.

[1] https://github.com/pyca/cryptography/issues/5771
[2] https://github.com/python/cpython/pull/24534
[3] https://bugs.python.org/issue43179

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Fwd: [Python-Dev] Move support of legacy platforms/architectures outside Python

[Alec Warner]

So my question is basically, how much does Gentoo care about these
ports? Should we be funding ports of rust to these arches (assuming
that would continue ensure gentoo works on those arches.)

-A


On Sun, Feb 21, 2021 at 5:01 AM Michał Górny <mgorny@gentoo.org> 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.
>
>
> -------- 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/
>
> --
> Best regards,
> Michał Górny
>
>
>

Re: [gentoo-dev] Fwd: [Python-Dev] Move support of legacy platforms/architectures outside Python

[Michał Górny]

On Mon, 2021-02-22 at 22:16 -0800, Alec Warner wrote:
> So my question is basically, how much does Gentoo care about these
> ports? Should we be funding ports of rust to these arches (assuming
> that would continue ensure gentoo works on those arches.)

I think it's too early to say.  So far Python devs have not admitted any
relevance between Python supported architectures and Rust supported
architectures.  It is still possible that they would wish to block minor
architectures even if Rust were ported there.

On the other hand, what we need right now is a major effort towards
making Rust installable on the Gentoo architectures that are supported
by Rust upstream.  Maybe our Rust developers would use some funding to
be able to dedicate more time into it.

-- 
Best regards,
Michał Górny