On Fri, Apr 8, 2022 at 5:03 AM Marc-Andre Lemburg firstname.lastname@example.org wrote:
On 06.04.2022 20:48, Brett Cannon wrote:
Last chance on whether my tier 3 proposal make sense! I will take
acceptance and plan to convert any current tier 2 platform with a single
dev to tier 3 and then ask the SC to approve/reject the list of
will also update the PEP about expectations of when things must be
stable before b1, else a warning goes out that a platform risks being
the RC (regardless of tier).
I will also be filling out the tiers to include the vendor, but I will
*since I haven't come across the latter online
come across the former regularly (e.g. https://doc.rust-lang.org/nightly/rustc/platform-support.html).
Could you please post the current proposal somewhere to read in one complete piece ? It's become hard to figure out what is on the table at the moment and the PR also doesn't appear to be up to date:
The PR is now up-to-date! For ease of reference, here's the critical part:
Platform support is broken down into *tiers*. Each tier comes with different requirements which lead to different promises being made about support.
To be promoted to a tier, steering council support is required and is expected to be driven by team consensus. Demotion to a lower tier occurs then the requirements of the current tier are no longer met for a platform for an extended period of time based on the judgment of the release manager or steering council. For platforms which no longer meet the requirements of any tier by b1 of a new feature release, an announcement will be made to warn the community of the pending removal of support for the platform (e.g. in the b1 announcement). If the platform is not brought into line for at least one of the tiers by the first release candidate, it will be listed as unsupported in this PEP.
mainbranch are not allowed to be
merged; any breakage should be fixed or reverted immediately.
main, and thus these platforms, working.
======================== ===== Target Triple Notes ======================== ===== i686-pc-windows-msvc x86_64-pc-windows-msvc x86_64-apple-darwin BSD libc, clang x86_64-unknown-linux-gnu glibc, gcc ======================== =====
=========================== ========================== ============================================== ======== Target Triple Notes Buildbot Contacts =========================== ========================== ============================================== ======== aarch64-apple-darwin clang https://buildbot.python.org/all/#/builders/725 Ned Deily, Ronald Oussoren, Dong-he Na aarch64-unknown-linux-gnu glibc, gcc https://buildbot.python.org/all/#/builders/125 Petr Viktorin, Victor Stinner
https://buildbot.python.org/all/#/builders/234 Victor Stinner, Gregory P. Smith powerpcle-unknown-linux-gnu glibc, gcc https://buildbot.python.org/all/#/builders/90 Petr Viktorin, Victor Stinner x86_64-unknownlinux-gnu glibc, clang https://buildbot.python.org/all/#/builders/441 Victor Stinner, Gregory P. Smith =========================== ========================== ============================================== ========
=========================== ========================== ============================================== ======== Target Triple Notes Buildbot Contacts =========================== ========================== ============================================== ======== aarch64-pc-windows-msvc https://buildbot.python.org/all/#/builders/729 Steve Dower powerpcle-unknown-linux-gnu glibc, clang https://buildbot.python.org/all/#/builders/435 Victor Stinner x86_64-unknown-freebsd BSD libc, clang https://buildbot.python.org/all/#/builders/172 Victor Stinner =========================== ========================== ============================================== ========
Support for a platform may be partial within the code base, such as from active development around platform support or accidentally. Code changes to platforms not listed in the above tiers may rejected or removed from the code base without a deprecation process if they cause a maintenance burden or obstruct general improvements.
Platforms not listed here may be supported by the wider Python community in some way. If your desired platform is not listed above, please perform a search online to see if someone is already providing support in some form.
On Fri, Apr 1, 2022 at 6:50 PM Victor Stinner <email@example.com mailto:firstname.lastname@example.org> wrote:
On Fri, Apr 1, 2022 at 11:19 PM Christian Heimes <
<mailto:email@example.com>> wrote: > How about: > > * a buildbot is required. For a transition period a public CI
> that runs Python's test suite at least once per day, is also
> > * at least one active contributor who acts as a point of contact, > monitors CI and provides fixes in a timely fashion. Sadly, I'm not sure that a regular contributor is enough to get fixes merged even fixes are written. Maybe it's better to require one core dev per Tier 3 platform. What if tomorrow someone sets up a MinGW buildbot. Is it enough to promote MinGW as Tier 3? There are many MinGW patches awaiting in the bug tracker for *years* and nobody is available to review and merged them. (I didn't check recently, maybe some of them have been merged
the meanwhile?) For the buildbot, IMO it's important that the whole test suite pass. I'm fine with skipping a large number of tests. But a single failure makes a buildbot really annoying, barely usuable, because buildbots are unable to say if a change adds more errors than previously. It's
boolean: either all tests pass, or "at least one test fails": you
to dig into logs to know the exact number :-( Victor -- Night gathers, and now my watch begins. It shall not end until my
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Apr 08 2022)
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/