On Fri, Mar 11, 2022 at 12:37 PM Gregory P. Smith <g...@krypto.org> wrote:
> > 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." > I'm fine with that. It still lets those of us working on WebAssembly to upstream stuff but we can't claim full support until we get a Buildbot which seems fair. > > 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. > I think it's more about making sure if we are going to let a Buildbot run block a release we want to make sure that it's reliable enough to use for that purpose. I think using the term "stable" is unfortunately overloaded, so I won't plan to use it. -Brett > > > .. [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/IPJPO4LBBCGICDFLHFR6WTEG3AT7J3TA/ Code of Conduct: https://www.python.org/psf/codeofconduct/
