Consider adding a Tier 3 to tiered platform support
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).
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.
--
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!
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
Victor
Night gathers, and now my watch begins. It shall not end until my death.
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)
*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).
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
mainfor 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/
I like your proposal better than mine :-) I agree that my Tier 3's constraints were too weak :-(
On Fri, Apr 1, 2022 at 9:22 PM Brett Cannon <brett@python.org> wrote:
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.
After sending my email, I realized that "the grumpy user" would use the lack of buildbot as an argument to keep the platform: the platform is working since there is no red buildbot!
Yeah, sadly, I have no idea of the current status of the Android support. Maybe it's mostly ok. Maybe it's badly broken.
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)
Here's my counter-proposal.
Tier 3:
- 1 core dev
Yeah sadly, it's hard to find 2 volunteers for these less common platforms.
- Buildbot
- SC/consensus approval to be added/removed
IMO a platform must have a running buildbot and the buildbot must not fail for at least 2 weeks to be considered as good enough to enter Tier 3. It should be a pre-condition to consider adding a platform to a Tier. That's different from the current PEP 11 which says that "having a buildbot" is enough, it doesn't specify if it should work or not.
- 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)
PPC64 AIX, x86-64 FreeBSD, s390x Linux and SPARCv9 Solaris have a buildbot.
I'm ok to maintain ("best effort"!) FreeBSD and s390x Linux.
I'm not interested to maintain AIX and Solaris. If no core dev is volunteer to maintain them, according to your proposal, they don't belong to Tier 3.
Maybe we should write down that a broken Tier 3 platform doesn't qualify to revert a Python commit.
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 (...)
IMO it's a good rule and it's good to have it written down to avoid complains later.
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.
Honestly, AIX and Solaris are in a bad shape. Tests are failing for a several weeks as you noticed. If the PEP 11 is deeply updated, it's a good opportunity to start from a smaller but better platform subset.
Adding AIX and Solaris to Tier 3 can be considered later, once all issues are fixed and a *core dev* will be actively fixing regressions specific to these platforms.
Next question: should we drop buildbots when the SC decides to no longer support the platform? For a new platform which is not in Tier 3 yet, how can it enter Tier 3 if it doesn't have a buildbot?
In the past, what I did is to disable email notficiations for AIX because no core dev was fixing issues. The buildbot was still running, bugs were known for months, but nobody fixed them.
Victor
Night gathers, and now my watch begins. It shall not end until my death.
On 01/04/2022 01.40, Victor Stinner 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
As Brett pointed out a tier 3 platform does not make much sense if we have no means to test the platform. I also would like to nudge vendors to contribute resources like build bots or engineering time. We want a low bar for contributions. No bar is too low. :)
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.
Christian
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.
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
unknowninstead 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 <vstinner@python.org <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 Fri, Apr 8, 2022 at 5:03 AM Marc-Andre Lemburg <mal@egenix.com> 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
On 06.04.2022 20:48, Brett Cannon wrote: 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
unknowninstead 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:
The PR is now up-to-date! For ease of reference, here's the critical part:
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
mainbranch 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, clanghttps://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 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.
-Brett
Thanks.
On Fri, Apr 1, 2022 at 6:50 PM Victor Stinner <vstinner@python.org <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 mergedin 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'sa 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 mydeath.
-- 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 <mal@egenix.com <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/filesThe 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
mainbranch 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 Stinnerglibc, 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/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 <mal@egenix.com <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/filesThe 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
mainbranch 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, clanghttps://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/
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 <mal@egenix.com <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/filesThe 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
mainbranch 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, clanghttps://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/
On Tue, Apr 19, 2022 at 12:36 AM Brett Cannon <brett@python.org> wrote:
And now the PR is merged! https://github.com/python/peps/pull/2442
Wow! That's huge! Thanks you so much Brett for handling this heavy task! It has been discussed for like 5 years at least.
It's great to have a way more *practical* definition of platform support and rules to move platform support between the 3 tiers.
I am happy that Tier 3 was adopted for FreeBSD and the ppc64le arch.
It's also good that Solaris and AIX support is now well defined: they are not supported by Python, even if there are buildbots. Previously, a buildbot on python.org was seen as "this platform is supported by Python". I was confused by that and sometimes I didn't know if I *had to* fix AIX regressions for example.
Sadly, past experiences showed us that a lack of an *active* core dev fail to keep a platform supported in the long term. A core dev is required to fix regressions specific to a platform.
Victor
participants (7)
-
Brett Cannon -
Christian Heimes -
Ethan Furman -
Gregory P. Smith -
M.-A. Lemburg -
Marc-Andre Lemburg
-
Victor Stinner