On Fri, Apr 1, 2022 at 12:22 PM Brett Cannon brett@python.org wrote:

On Thu, Mar 31, 2022 at 4:40 PM Victor Stinner vstinner@python.org wrote:

...

Hi,

I don't think that the current PEP 11 draft (*) describes correctly the current status of a bunch of platforms which are not "actively" supported. I like to call these plaforms as "best effort support" platforms. I propose considering adding an explicit "Tier 3" to PEP 11.

(*) https://github.com/python/peps/pull/2442/

Rust defines its Tier 3 as: "Tier 3 targets are those which the Rust codebase has support for, but which the Rust project does not build or test automatically, so they may or may not work."

Tier 3 requirements would be *very weak*:

• No buildbot requirement
• No assigned core dev needed
• Don't revert a change breaking a Tier 3 platform
• Don't hold a Python release if a Tier 3 platform is broken

...

Currently, the "All other platforms" section is quite clear: code can be removed anytime:

"Code changes to platforms not listed in the above tiers may rejected or removed from the code base *without a deprecation process* if they cause a maintenance burden or obstruct general improvements."

The only difference between "Tier 3" and "All other platforms" would be that removing a platform from Tier 3 require a process. I'm not sure if a deprecation is needed. But we have to go through a discussion and someone (SC?) has to decide if it's ok to drop it (remove code).

If there's no buildbot making sure the platform works and no core dev trying to keep it working, then what's the point of listing the platform in the PEP? Otherwise I feel that listing a platform as tier 3 just says, "there's some code in main for it, but we have no clue if it works and we won't necessarily try to make it work." And if that's the case then why do we need to keep the code around and the cost of readability of our code base?

...

Removing code from Python means in practice that the support *can* still continue, but outside of the Git upstream repository: in a fork instead.

For me the main threat of (adding a platform to) Tier 3 is the risk that we might never ever able to drop support for these platforms. PEP 11 would be used by users as a holy document. Maybe we should be clear that Tier 3 is not a strong warranty of long term support, but is just a weak status. For example, put a time bomb: if no developer was available in the last 12 month to fix regressions, drop the platform for Tier 3.

But without a buildbot how do we know when there are regressions and when that regression occurred? I wouldn't even know when those 12 months started w/ this proposal.

...

--

I'm thinking at these platforms for Tier 3:

• AIX 6.4 and newer (has a buildbot)
• Android API 24
• FreeBSD
• OpenBSD
• NetBSD
• s390x arch
• Solaris (has a buildbot)

I would prefer to put FreeBSD and s390x in Tier 3 rather than Tier 2.

Users of these platforms and contributors who added support for these platforms are going to be grumpy if we drop such platform without any warning or process.

Android support seems to be stale for now. But I would prefer to keep it for now.

--

Last year, I proposed to drop immediately Solaris support (remove code):

https://mail.python.org/archives/list/python-dev@python.org/thread/VDD7NMEDF...

I read that Solaris was no longer maintained by Oracle. I was wrong. Moreover, many Python users on Solaris started to complained loudly. Not only Solaris is maintained, but it's also under active development. After this thread, Oracle contributed Solaris patches to Python, and set up a buildbot!

If you're referring to https://buildbot.python.org/all/#/workers/47 then it hasn't passed a build in months.

...

I suggest thinking twice before adding a platform to Tier 3. Adding it is easy. But there will always be at least *one* very grumpy Python user of this platform who will fight to death to keep his old precious unmaintained broken platform, even if no one else in the world has access to the hardware (no longer sold) and no one is able to fix regressions.

--

For now, I would prefer to *not* add the following platforms to Tier 3. Keep them in the gray area of "unsupported" platforms.

• DOS
• Cygwin
• HP-UX
• MinGW
• VMS (OpenVMS): https://vmspython.org/

Time to time, I merge HP-UX fixes if someone proposes a fix and I have some free cycle to review it. Once, I fixed one Unicode issue specific to HP-UX without having access to HP-UX. It's not the most efficient development method for me: it requires a lot of back and forth exchanges with a developer having access to this platform. I don't want to list HP-UX in Tier 3: I don't have access to HP-UX.

--

My notes on platforms supported by Python: https://pythondev.readthedocs.io/platforms.html

Here's my counter-proposal.

Tier 3:

• 1 core dev
• Buildbot
• SC/consensus approval to be added/removed
• Can have a directory in Tools/ to maintain things such as build configs (see https://github.com/python/cpython/tree/main/Tools/wasm as an example)

Clarify that Tier 3 doesn't have release blocker status. I'm not sure we should maintain that as a list in a PEP... but I'm not going to object given we're saying it won't just be random edits by requiring SC/consensus approval to change the list.

*All* tiers:

• If a platform is not supported and stable by beta, there will be an announcement (probably in What's New) about how the platform is slated to not be officially supported in this release and we plan to drop support completely for the platform in the final release unless the situation is resolved by RC.

That would give the community 3 months between b1 and rc1 to work with the core dev who has volunteered to make that platform work again (if it stops working; hoping that won't happen). And being in tier 3 means the community knows upfront that they have to test the betas and make sure things are working appropriately, so there's no surprises.

We can also give all tier 3 platforms a "pass" for 3.11 where we won't trigger any of this until 3.12b1 so there's enough time to line up a Buildbot and core dev.

But even though I have a counter-proposal, I would still prefer to hear people weigh in with their opinions on whether this tier 3 platform support is worth it (either Victor's or my idea for it).

---

python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/6... Code of Conduct: https://www.python.org/psf/codeofconduct/

Last chance on whether my tier 3 proposal make sense! I will take silence as acceptance and plan to convert any current tier 2 platform with a single core dev to tier 3 and then ask the SC to approve/reject the list of platforms. I will also update the PEP about expectations of when things must be considered stable before b1, else a warning goes out that a platform risks being dropped in the RC (regardless of tier).

I will also be filling out the tiers to include the vendor, but I will be using unknown instead of * since I haven't come across the latter online while I come across the former regularly (e.g. https://doc.rust-lang.org/nightly/rustc/platform-support.html).

On Fri, Apr 1, 2022 at 6:50 PM Victor Stinner vstinner@python.org wrote:

On Fri, Apr 1, 2022 at 11:19 PM Christian Heimes christian@python.org wrote:

...

How about:

• a buildbot is required. For a transition period a public CI system, that runs Python's test suite at least once per day, is also acceptable.

• at least one active contributor who acts as a point of contact, monitors CI and provides fixes in a timely fashion.

Sadly, I'm not sure that a regular contributor is enough to get fixes merged even fixes are written. Maybe it's better to require one core dev per Tier 3 platform.

What if tomorrow someone sets up a MinGW buildbot. Is it enough to promote MinGW as Tier 3? There are many MinGW patches awaiting in the bug tracker for *years* and nobody is available to review and merged them. (I didn't check recently, maybe some of them have been merged in the meanwhile?)

For the buildbot, IMO it's important that the whole test suite pass. I'm fine with skipping a large number of tests. But a single failure makes a buildbot really annoying, barely usuable, because buildbots are unable to say if a change adds more errors than previously. It's a boolean: either all tests pass, or "at least one test fails": you have to dig into logs to know the exact number :-(

Victor

Night gathers, and now my watch begins. It shall not end until my death.

---

python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/M... Code of Conduct: https://www.python.org/psf/codeofconduct/

On 06.04.2022 20:48, Brett Cannon wrote:

Last chance on whether my tier 3 proposal make sense! I will take silence as acceptance and plan to convert any current tier 2 platform with a single core dev to tier 3 and then ask the SC to approve/reject the list of platforms. I will also update the PEP about expectations of when things must be considered stable before b1, else a warning goes out that a platform risks being dropped in the RC (regardless of tier).

I will also be filling out the tiers to include the vendor, but I will be using unknown instead of * since I haven't come across the latter online while I come across the former regularly (e.g. https://doc.rust-lang.org/nightly/rustc/platform-support.html).

Could you please post the current proposal somewhere to read in one complete piece ? It's become hard to figure out what is on the table at the moment and the PR also doesn't appear to be up to date:

https://github.com/python/peps/pull/2442/files

Thanks.

On Fri, Apr 1, 2022 at 6:50 PM Victor Stinner mailto:vstinner@python.org> wrote:

On Fri, Apr 1, 2022 at 11:19 PM Christian Heimes <christian@python.org
<mailto:christian@python.org>> wrote:
> How about:
>
> * a buildbot is required. For a transition period a public CI system,
> that runs Python's test suite at least once per day, is also acceptable.
>
> * at least one active contributor who acts as a point of contact,
> monitors CI and provides fixes in a timely fashion.

Sadly, I'm not sure that a regular contributor is enough to get fixes
merged even fixes are written. Maybe it's better to require one core
dev per Tier 3 platform.

What if tomorrow someone sets up a MinGW buildbot. Is it enough to
promote MinGW as Tier 3? There are many MinGW patches awaiting in the
bug tracker for *years* and nobody is available to review and merged
them. (I didn't check recently, maybe some of them have been merged in
the meanwhile?)

For the buildbot, IMO it's important that the whole test suite pass.
I'm fine with skipping a large number of tests. But a single failure
makes a buildbot really annoying, barely usuable, because buildbots
are unable to say if a change adds more errors than previously. It's a
boolean: either all tests pass, or "at least one test fails": you have
to dig into logs to know the exact number :-(

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Experts (#1, Apr 08 2022)

...

...

Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/

::: We implement business ideas - efficiently in both time and costs :::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/

On 09.04.2022 02:13, Brett Cannon wrote:

On Fri, Apr 8, 2022 at 5:03 AM Marc-Andre Lemburg mailto:mal@egenix.com> wrote:

On 06.04.2022 20:48, Brett Cannon wrote:
 > Last chance on whether my tier 3 proposal make sense! I will take
silence as
 > acceptance and plan to convert any current tier 2 platform with a
single core
 > dev to tier 3 and then ask the SC to approve/reject the list of
platforms. I
 > will also update the PEP about expectations of when things must
be considered
 > stable before b1, else a warning goes out that a platform risks
being dropped in
 > the RC (regardless of tier).
 >
 > I will also be filling out the tiers to include the vendor, but I
will be using
 > `unknown` instead of `*` since I haven't come across the latter
online while I
 > come across the former regularly (e.g.
 > https://doc.rust-lang.org/nightly/rustc/platform-support.html).

Could you please post the current proposal somewhere to read in
one complete piece ? It's become hard to figure out what is on
the table at the moment and the PR also doesn't appear to be
up to date:

https://github.com/python/peps/pull/2442/files

The PR is now up-to-date! For ease of reference, here's the critical part:

Thanks, Brett.

Support tiers

Platform support is broken down into *tiers*. Each tier comes with different requirements which lead to different promises being made about support.

To be promoted to a tier, steering council support is required and is expected to be driven by team consensus. Demotion to a lower tier occurs then the requirements of the current tier are no longer met for a platform for an extended period of time based on the judgment of the release manager or steering council. For platforms which no longer meet the requirements of any tier by b1 of a new feature release, an announcement will be made to warn the community of the pending removal of support for the platform (e.g. in the b1 announcement). If the platform is not brought into line for at least one of the tiers by the first release candidate, it will be listed as unsupported in this PEP.

Tier 1

• CI failures <https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>__ block releases.
• Changes which would break the main branch are not allowed to be merged; any breakage should be fixed or reverted immediately.
• All core developers are responsible to keep main, and thus these platforms, working.
• Failures on these platforms **block a release**.

======================== ===== Target Triple            Notes ======================== ===== i686-pc-windows-msvc x86_64-pc-windows-msvc x86_64-apple-darwin      BSD libc, clang x86_64-unknown-linux-gnu glibc, gcc ======================== =====

Tier 2

• Must have a reliable buildbot.
• At least **two** core developers are signed up to support the platform.
• Changes which break any of these platforms are to be **fixed or reverted within 24 hours**.
• Failures on these platforms **block a release**.

=========================== ========================== ============================================== ======== Target Triple               Notes                      Buildbot
Contacts =========================== ========================== ============================================== ======== aarch64-apple-darwin        clang https://buildbot.python.org/all/#/builders/725 Ned Deily, Ronald Oussoren, Dong-he Na aarch64-unknown-linux-gnu   glibc, gcc https://buildbot.python.org/all/#/builders/125 Petr Viktorin, Victor Stinner

                            glibc, clang https://buildbot.python.org/all/#/builders/234 Victor Stinner, Gregory P. Smith powerpcle-unknown-linux-gnu glibc, gcc https://buildbot.python.org/all/#/builders/90  Petr Viktorin, Victor Stinner x86_64-unknownlinux-gnu     glibc, clang https://buildbot.python.org/all/#/builders/441 Victor Stinner, Gregory P. Smith =========================== ========================== ============================================== ========

Tier 3

• Must have a reliable buildbot.
• At least **one** core developer is signed up to support the platform.
• No response SLA to failures.
• Failures on these platforms do **not** block a release.

=========================== ========================== ============================================== ======== Target Triple               Notes                      Buildbot
Contacts =========================== ========================== ============================================== ======== aarch64-pc-windows-msvc https://buildbot.python.org/all/#/builders/729 Steve Dower powerpcle-unknown-linux-gnu glibc, clang https://buildbot.python.org/all/#/builders/435 Victor Stinner x86_64-unknown-freebsd      BSD libc, clang https://buildbot.python.org/all/#/builders/172 Victor Stinner =========================== ========================== ============================================== ========

All other platforms

Support for a platform may be partial within the code base, such as from active development around platform support or accidentally. Code changes to platforms not listed in the above tiers may rejected

Should read: "may be rejected"

or removed from the code base without a deprecation process if they cause a maintenance burden or obstruct general improvements.

Platforms not listed here may be supported by the wider Python community in some way. If your desired platform is not listed above, please perform a search online to see if someone is already providing support in some form.

+1 on this version.

Thanks for writing this up, Brett.

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Experts (#1, May 24 2017)

...

...

Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/

::: We implement business ideas - efficiently in both time and costs :::

eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
        Registered at Amtsgericht Duesseldorf: HRB 46611
            http://www.egenix.com/company/contact/
                   http://www.malemburg.com/

And now the PR is merged! https://github.com/python/peps/pull/2442

Thanks to everyone who provided input! When I get a chance I will work to get tier labels added to the appropriate buildbots and then update the PEP to link to those queries instead of individual buildbots.

On Mon, Apr 11, 2022 at 1:31 PM Brett Cannon brett@python.org wrote:

On Sat, Apr 9, 2022 at 5:04 AM M.-A. Lemburg mal@egenix.com wrote:

...

On 09.04.2022 02:13, Brett Cannon wrote:

...

On Fri, Apr 8, 2022 at 5:03 AM Marc-Andre Lemburg mailto:mal@egenix.com> wrote:

On 06.04.2022 20:48, Brett Cannon wrote:
 > Last chance on whether my tier 3 proposal make sense! I will take
silence as
 > acceptance and plan to convert any current tier 2 platform with a
single core
 > dev to tier 3 and then ask the SC to approve/reject the list of
platforms. I
 > will also update the PEP about expectations of when things must
be considered
 > stable before b1, else a warning goes out that a platform risks
being dropped in
 > the RC (regardless of tier).
 >
 > I will also be filling out the tiers to include the vendor, but I
will be using
 > `unknown` instead of `*` since I haven't come across the latter
online while I
 > come across the former regularly (e.g.
 > https://doc.rust-lang.org/nightly/rustc/platform-support.html).

Could you please post the current proposal somewhere to read in
one complete piece ? It's become hard to figure out what is on
the table at the moment and the PR also doesn't appear to be
up to date:

https://github.com/python/peps/pull/2442/files

The PR is now up-to-date! For ease of reference, here's the critical

part:

Thanks, Brett.

...

Support tiers

Platform support is broken down into *tiers*. Each tier comes with different requirements which lead to different promises being made about support.

To be promoted to a tier, steering council support is required and is expected to be driven by team consensus. Demotion to a lower tier occurs then the requirements of the current tier are no longer met for a platform for an extended period of time based on the judgment of the release manager or steering council. For platforms which no longer meet the requirements of any tier by b1 of a new feature release, an announcement will be made to warn the community of the pending removal of support for the platform (e.g. in the b1 announcement). If the platform is not brought into line for at least one of the tiers by the first release candidate, it will be listed as unsupported in this PEP.

Tier 1

• CI failures < https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>__

...

block releases.

• Changes which would break the main branch are not allowed to be merged; any breakage should be fixed or reverted immediately.
• All core developers are responsible to keep main, and thus these platforms, working.
• Failures on these platforms **block a release**.

======================== ===== Target Triple Notes ======================== ===== i686-pc-windows-msvc x86_64-pc-windows-msvc x86_64-apple-darwin BSD libc, clang x86_64-unknown-linux-gnu glibc, gcc ======================== =====

Tier 2

• Must have a reliable buildbot.
• At least **two** core developers are signed up to support the platform.
• Changes which break any of these platforms are to be **fixed or reverted within 24 hours**.
• Failures on these platforms **block a release**.

=========================== ========================== ============================================== ======== Target Triple Notes Buildbot Contacts =========================== ========================== ============================================== ======== aarch64-apple-darwin clang https://buildbot.python.org/all/#/builders/725 Ned Deily, Ronald Oussoren, Dong-he Na aarch64-unknown-linux-gnu glibc, gcc https://buildbot.python.org/all/#/builders/125 Petr Viktorin, Victor Stinner

                         glibc, clang

https://buildbot.python.org/all/#/builders/234 Victor Stinner, Gregory P. Smith powerpcle-unknown-linux-gnu glibc, gcc https://buildbot.python.org/all/#/builders/90 Petr Viktorin, Victor Stinner x86_64-unknownlinux-gnu glibc, clang https://buildbot.python.org/all/#/builders/441 Victor Stinner, Gregory P. Smith =========================== ========================== ============================================== ========

Tier 3

• Must have a reliable buildbot.
• At least **one** core developer is signed up to support the platform.
• No response SLA to failures.
• Failures on these platforms do **not** block a release.

=========================== ========================== ============================================== ======== Target Triple Notes Buildbot Contacts =========================== ========================== ============================================== ======== aarch64-pc-windows-msvc https://buildbot.python.org/all/#/builders/729 Steve Dower powerpcle-unknown-linux-gnu glibc, clang https://buildbot.python.org/all/#/builders/435 Victor Stinner x86_64-unknown-freebsd BSD libc, clang https://buildbot.python.org/all/#/builders/172 Victor Stinner =========================== ========================== ============================================== ========

All other platforms

Support for a platform may be partial within the code base, such as from active development around platform support or accidentally. Code changes to platforms not listed in the above tiers may rejected

Should read: "may be rejected"

Fixed!

...

...

or removed from the code base without a deprecation process if they cause a maintenance burden or obstruct general improvements.

Platforms not listed here may be supported by the wider Python community in some way. If your desired platform is not listed above, please perform a search online to see if someone is already providing support in some form.

+1 on this version.

Thanks for writing this up, Brett.

Welcome!

We didn't get to this PR in today's SC meeting, but I'm hoping to get SC sign-off next week.

-Brett

...

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Experts (#1, May 24 2017)

...

...

...

Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/

---

::: We implement business ideas - efficiently in both time and costs :::

eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
        Registered at Amtsgericht Duesseldorf: HRB 46611
            http://www.egenix.com/company/contact/
                   http://www.malemburg.com/