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/VDD7NMEDFXMOP4S74GEYJUHJRJPK2UR3/
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
Here's my counter-proposal.
Tier 3:
- 1 core dev
- Buildbot
- SC/consensus approval to be added/removed
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).