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