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.