On Fri, Mar 11, 2022 at 10:45 AM Brett Cannon <br...@python.org> wrote:
> > On Fri, Mar 11, 2022 at 9:16 AM Paul Moore <p.f.mo...@gmail.com> wrote: > >> On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg <m...@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
_______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/YPQ7H5HD3X2EY522M75OM6CQQZNLWWOD/ Code of Conduct: https://www.python.org/psf/codeofconduct/
