On 04. 03. 22 21:48, Brett Cannon wrote:
On Fri, Mar 4, 2022 at 1:44 AM Petr Viktorin <encukou@gmail.com <mailto:encukou@gmail.com>> wrote:
On 04. 03. 22 0:30, Brett Cannon wrote: > Do we officially support NetBSD? Do you know how to find out if we do? > You might think to look at > https://www.python.org/dev/peps/pep-0011/#supporting-platforms <https://www.python.org/dev/peps/pep-0011/#supporting-platforms> > <https://www.python.org/dev/peps/pep-0011/#supporting-platforms <https://www.python.org/dev/peps/pep-0011/#supporting-platforms>> , but > that just loosely defines the criteria and it still doesn't list the > actual platforms we support. (BTW I don't know if we do officially > support NetBSD, hence this email.) > > I think we should clarify this sort of thing and be a bit more upfront > with the level of support we expect/provide for a platform. As such, I > want to restructure PEP 11 to list the platforms we support, not just > list the platforms we stopped supporting. To do this I want define 3 > different tiers that outline what our support requirements and promises > are for platforms.
While you're at it: consider moving the lists to the devguide, so the PEP would only contain the general process & criteria.
Why the devguide? I view the list of platforms as important for public consumption as for the core dev team to know what to (not) accept PRs for.
So, let's put it in the main docs? Yes, I guess the devguide is a weird place to check for this kind of info. But a Python enhancement proposal is even weirder.
> Tier 1 is the stuff we run CI against: latest Windows, latest macOS, > Linux w/ the latest glibc (I don't know of a better way to define Linux > support as I don't know if a per-distro list is the right abstraction). > These are platforms we won't even let code be committed for if they > would break; they block releases if they don't work. These platforms we > all implicitly promise to support. > > Tier 2 is the platforms we would revert a change within 24 hours if they > broke: latest FeeBSD, older Windows, older macOS, Linux w/ older > glibc.This is historically the "stable buildbot plus a core dev" group > of platforms. The change I would like to see is two core devs (in case > one is on vacation), and a policy as to how a platform ends up here > (e.g. SC must okay it based on consensus of everyone). The stable > buildbot would still be needed to know if a release is blocked as we > would hold a release up if they were red. The platform and the core devs > supporting these platforms would be listed in PEP 11.
Do we need two core devs to revert changes?
No, but consider you are trying to land something before b1 and a tier 2 platform keeps failing. You have no idea why, but e.g. Victor is on vacation and is unavailable to help. I personally wouldn't want to wait until the next version of Python just because a platform we say we support had its expert take an inconvenient vacation.
Sure, requiring two core devs will help with that. But two seems about as arbitrary as one. People can have overlapping vacations, and some core devs are less responsive than Victor on vacation :) Is this an existing, recurring issue we need to solve?