On Fri, Mar 11, 2022 at 10:45 AM Brett Cannon firstname.lastname@example.org wrote:
On Fri, Mar 11, 2022 at 9:16 AM Paul Moore email@example.com wrote:
On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg firstname.lastname@example.org 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.
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].