On 04. 03. 22 21:48, Brett Cannon wrote:
On Fri, Mar 4, 2022 at 1:44 AM Petr Viktorin <encu...@gmail.com
<mailto:encu...@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?
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/XTRF3IH4LN3Z6RC6KGS5IJCWMTL3GAYL/
Code of Conduct: http://python.org/psf/codeofconduct/
