On Fri, Mar 4, 2022 at 1:44 AM Petr Viktorin <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> , 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. > > > > 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. > What are the duties of someone listed for a platform, anyway? > I would expect they would be the reviewer of PRs for that platform. Also domain expert to help out with questions as they arise if their platform could potentially block a release or feature getting in. > > > Tier 3 are platforms we accept PRs for to keep working, but they won't > > block a release. At least one core dev must be listed to be in charge of > > PRs that affect the platform. A buildbot would be nice but not required. > > I'm thinking either historical platforms we support or something like > > Emscripten that's working towards being a tier 2 platform. I'm not sure > > if we want to have explicit approval to be in this tier beyond the > > outlined requirements, but obviously if a core dev isn't keeping up with > > PRs then the platform will be dropped. > > > > All other platforms we do not directly support in the repository and it > > is up to the community to keep functioning. We can obviously keep > > accepting general patches to up compatibility, but platform-specific > > patches for anything outside of these tiers wouldn't. No issue if > > someone provides a buildbot for their own benefit, but these buildbots > > would never hold anything up. > > > > When a Python version hits b1, then that platform is considered > > supported for that version as long as the requirements outlined above > > continue to be met. Once the Python version hits EOL then like anything, > > support ends no matter what. We could capture the supported platforms > > for a version in the release schedule PEP if people want > > > I would expect appropriate labels being added to the builders listed at > > https://buildbot.python.org/all/#/builders > > <https://buildbot.python.org/all/#/builders> to signify which platforms > > we block releases for (e.g. `tier-1,`, `tier-2`, or `release-blocker` as > > a generic label). > > > > I would expect PEP 11 to list the appropriate C symbol that's set for > > that platform, e.g. __linux__. > > > > I don't know if we want to bother listing CPU architectures since we are > > a pure C project which makes CPU architecture less of a thing, but I'm > > personally open to the idea of CPU architectures being a part of the > > platform definition. > > IMO it would be good to be explicit wrt. testing and support. There's a > lot of arch/compiler assumptions still hidden in the codebase. > 👍 As I replied to Christian, it seems people want explicit CPU architectures listed. -Brett > > > I don't think we should cover C compilers here as that's covered by PEP > > 7. Otherwise PEP 7 should only list C versions/features and PEP 11 lists > > compilers and their versions. > > I think it would be good to move that here. It's a “platform support” > matter, not “code style”. > > > FYI the tier support idea and the rough definitions above come from > > Rust: https://doc.rust-lang.org/nightly/rustc/platform-support.html > > <https://doc.rust-lang.org/nightly/rustc/platform-support.html> . > > > > _______________________________________________ > > 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/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > _______________________________________________ > 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/QXH2ZTE2DZOGVTZYW2TVQXXDF3XVYV7D/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/AJG43ESXYT3M37BOEOTKT7HKNDX5VR65/ Code of Conduct: http://python.org/psf/codeofconduct/
