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.