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