On Fri, Mar 11, 2022 at 10:45 AM Brett Cannon <brett@python.org> wrote:

On Fri, Mar 11, 2022 at 9:16 AM Paul Moore <p.f.moore@gmail.com> wrote:

On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg <mal@egenix.com> wrote:
>
> On 11.03.2022 17:42, Zachary Ware wrote:
> >
> > - Only code which either supports a higher-tier platform or is a general improvement may be checked in.
>
> My understanding of that sentence is: PRs which target platforms
> not listed in PEP 11 may not be checked in.
>
> IMO, it doesn't make sense to prohibit support code in the
> code base, if there is community interest in this. By dropping
> that line, we wouldn't have a problem and also don't
> need to list platforms in a tier 4 section, since it's still
> possible to add support in the main code base, without having
> a core dev maintain it.

I agree, the simplest solution here seems to be just to not include
that line. We can still push back on PRs for unsupported platforms if
we want, we just won't have a policy that *requires* us to do so.

If it turns out that leaving it to core devs' judgement is a problem,
we can agree a policy with some concrete examples to inform us.

It's already a guideline we hold, but I'm fine with weakening the language to make more of a cautious warning to only merge paltform-specific code if you have good reasons to.

I wouldn't word it as a prohibition.  Just get rid of the line entirely.

I'd also get rid of Tier 3.  It isn't useful - that tier doesn't block anything so we shouldn't be maintaining a documented list of things that come and go at that level.  That's pure makework and conveys nothing that the existence of a buildbot does not already do.

If you want a line to include about code supporting non tier1/2 platforms, I'd word it as:

"Code changes to support platforms beyond tier1 or tier2 may be rejected, broken, or removed from the CPython codebase without notice if they cause a maintenance burden for tier1&2 or obstruct general improvements."

This simplifies the story and better reflects reality.  Things listed in a tier are meaningful without 3 because they block releases rather than needing to know that tier 3 is a no-op.

The buildbot concept of "stable" is arbitrary.  It is a configuration tag.  There is no strict authority to gatekeep and curate it.  If a release manager or steering council said to remove the "stable" tag from a buildbot they'd likely be listened to. Otherwise it's collectively up to whomever maintains the bot configs and approves the config PRs.  Stability of a machine setup for reliability purposes is unrelated to importance.

Ex: I don't tag my raspbian bot as "stable" because it lives at home where I provide a SLO of nothing.  It has nothing to do with importance.  It is clearly a more important platform than wasm today.

> .. [ubuntu-20_01]

Call this link ubuntu-20_04 to avoid confusion.  Ubuntu versions are always YY.04 and YY.10 unless they miss their planned release window [rare].

-gps