On Fri, Apr 1, 2022 at 12:22 PM Brett Cannon <br...@python.org> wrote:
> > On Thu, Mar 31, 2022 at 4:40 PM Victor Stinner <vstin...@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-...@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! >> > > 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-le...@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/6OGR3IEGXZW3YCBNWRSKYFKNFQRJ6RL4/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ >
_______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@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/3EJ3DDN6WTAGNIKWAOAJP6J7W52YK5XG/ Code of Conduct: https://www.python.org/psf/codeofconduct/
