On Fri, Mar 11, 2022 at 7:45 AM Marc-Andre Lemburg <mal@egenix.com> wrote:

If there are people in the community who wish to provide support for these platforms, I don't see a reason not to keep them in a tier 4. Such platforms would not be supported by the core team and don't necessarily need a buildbot (even though it would be good to have them).

I find it problematic that the way Brett has written the proposal essentially means that we will not accept any PRs to help support platforms which are not listed in the tables. Could be that I misinterpreted his writeup, though.

Esp. Android and possibly iOS are platforms which Python should be targeting in the future, since the story for Python on those platforms currently is pretty. We shouldn't make it harder to eventually gain such support and hopefully find new core devs who can maintain them to become fully supported.

As I understand it, the idea here is that if there is no core dev for a platform, it's not actually supported in a practical sense regardless of our official policy or lack thereof. The policy Brett is proposing just makes that explicit and gives us something to point to when someone comes up with a patch to support PDP-11 or when someone's patch for Android breaks Windows. I don't think we'll wind up with tier support police; if a core dev wants to take responsibility for a patch for a platform that is not tier 3 or above they can still do that, but if it breaks things for a supported platform it will be reverted.

If there is serious support for a non-tiered platform, all it takes is a buildbot and either an existing core dev to sign up to be the maintainer or for us to vote in a maintainer, and then it can be a tier 3 platform. If there's not someone actively maintaining it and the tests regularly being run on it, we can't realistically claim to support it anyway.

I don't see much value in a tier 4: all other platforms that aren't tier 3 or above are tier 4. We could link to a wiki page for where one might find links to support communities for non-tiered platforms, but I expect such a list would bitrot at a rate that makes it not worth including in the official tier list, whether by those communities fading away or the platform being promoted to tier 3.

On Thu, Mar 10, 2022 at 5:36 PM Brett Cannon <brett@python.org> wrote:

Tier 1

• Test suite failures <https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>__ block releases.
• Changes which would break the main branch are not allowed to be merged; any breakage may be reverted immediately.
• All core developers are responsible to keep these platforms working.
• Promotion of this tier requires consensus/SC approval.

Should tier 1 require pre-merge CI? We can currently do that, but promoting a platform that's not provided by GHA could require significant workflow changes.

• Must have a stable buildbot.

I have concerns about the term "stable buildbot". Until now, the "stable"/"unstable" tags on buildbots have been the closest thing we've had to a platform support policy and we've treated failures on a "stable" buildbot to be release blockers (for the most part). With a proper platform support policy, "stable"/"unstable" should become a description of the reliability of the particular worker machine to provide an accurate representation of the state of the tests on the platform rather than whether the tests usually pass, but I'm worried about confusion from the changing meaning of those labels.