I will give everyone another week, so until Friday, April 8th, to submit review changes to https://github.com/python/peps/pull/2442/ . Below is the list of platforms with stable buildbots that are lacking two core devs willing to be on the hook for helping support the platforms.
1. aarch64-windows-msvc (Steve is already listed) 2. powerpcle-linux-gnu glibc, clang 3. s390x-linux-gnu glibc, gcc 4. s390x-linux-gnu glibc, clang 5. x86_64-linux-gnu glibc, clang (Victor is already listed) 6. x86_64-unknown-freebsd BSD libc, cc (Victor is already listed) On Fri, Mar 25, 2022 at 12:32 PM Brett Cannon <br...@python.org> wrote: > Thanks to Petr, and Victor, the platforms that are still looking for a > total of two maintainers over at > https://github.com/python/peps/pull/2442/files are: > > 1. arch64-apple-darwin clang > 2. aarch64-linux-gnu glibc, clang (Victor is already listed) > 3. aarch64-windows-msvc > 4. powerpcle-linux-gnu glibc, clang > 5. s390x-linux-gnu glibc, gcc > 6. s390x-linux-gnu glibc, clang > 7. x86_64-linux-gnu glibc, clang (Victor is already listed) > 8. x86_64-unknown-freebsd BSD libc, cc (Victor is already listed) > > > On Thu, Mar 24, 2022 at 12:37 PM Brett Cannon <br...@python.org> wrote: > >> Based on the positive feedback that I've gotten on this and the only >> other suggestion was maybe bringing back tier 3 to represent, "being >> actively worked on" support (which i think we can add later if we feel it's >> worth it), I'm ready to ask folks to please start sending review >> suggestions on https://github.com/python/peps/pull/2442 to add yourself >> as supporting a platform (see >> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request >> if you don't know what I mean by "review suggestion"). >> >> I believe at least Victor is currently out at the moment, so I'm not >> planning to rush this out and start removing platforms that lack two people >> and merging this PR, but I also don't want to put it off either. As a >> reminder, the platforms looking for declared support as a tier 2 platform >> are: >> >> >> 1. arch64-apple-darwin clang >> 2. aarch64-linux-gnu glibc, gcc >> 3. aarch64-linux-gnu glibc, clang >> 4. aarch64-windows-msvc >> 5. powerpcle-linux-gnu glibc, gcc >> 6. powerpcle-linux-gnu glibc, clang >> 7. s390x-linux-gnu glibc, gcc >> 8. s390x-linux-gnu glibc, clang >> 9. x86_64-linux-gnu glibc, clang >> 10. x86_64-unknown-freebsd BSD libc, cc >> >> >> Tier 1 is taken care of: >> >> 1. i686-windows-msvc >> 2. x86_64-windows-msvc >> 3. x86_64-apple-darwin BSD libc, clang >> 4. x86_64-linux-gnu glibc, gcc >> >> >> On Thu, Mar 17, 2022 at 5:56 PM Brett Cannon <br...@python.org> wrote: >> >>> After considering everyone's feedback, here are my proposed explanations >>> for the tiers. >>> >>> Tier 1 >>> ------ >>> >>> - `CI failures < >>> https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>`__ >>> block releases. >>> - Changes which would break the ``main`` branch are not allowed to be >>> merged; >>> any breakage may be reverted immediately. >>> - All core developers are responsible to keep these platforms, >>> and thus ``main``, working. >>> - Promotion to this tier requires team consensus/SC approval. >>> >>> Tier 2 >>> ------ >>> >>> - Must have a reliable buildbot. >>> - At least **two** core developers are signed up to support the platform. >>> - Changes which break any of these platforms are to be fixed or >>> reverted within 24 hours. >>> - Failures on these platforms block a release. >>> - Promotion to this tier requires consensus/SC approval. >>> >>> All other platforms >>> ------------------- >>> >>> 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. >>> >>> >>> I have a draft PR up at https://github.com/python/peps/pull/2442 which >>> can be previewed at >>> https://pep-previews--2442.org.readthedocs.build/pep-0011/ (makes >>> reading the table much easier). I made the platforms list the platform >>> triple, libc, and compiler **without** version details. >>> >>> Once I have buy-in for the above I will explicitly ask folks to send >>> review comments to that PR to add themselves to the platforms they are >>> willing to support, and then drop any which lack two core developers >>> (warnings to the Fedora/RH folks: most of those platforms are listed are >>> using Fedora buildbots, so it might be up to you 😉). I did drop >>> powerpc-linux-gnu from the list as that buildbot has not successfully built >>> in quite some time (powerpcle seems fine). >>> >>> On Mon, Mar 14, 2022 at 5:35 PM Gregory P. Smith <g...@krypto.org> >>> wrote: >>> >>>> >>>> >>>> On Mon, Mar 14, 2022 at 11:43 AM Marc-Andre Lemburg <m...@egenix.com> >>>> wrote: >>>> >>>>> On 14.03.2022 19:34, Brett Cannon wrote: >>>>> > Greg proposed something like "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." and drop the concept of tier 3. Does that work for >>>>> you? >>>>> >>>>> Almost :-) I don't understand the "without notice". I guess Greg >>>>> meant "without deprecation process". Removal of support code should >>>>> be discussed on a ticket and then listed in PEP 11 and >>>>> mentioned in the NEWS file, as usual. >>>>> >>>> >>>> I guess I was trying to convey that we may not even have a way to know >>>> that we're breaking something on a non-tier1/2 platform anyways so "without >>>> notice" was just me trying to set people's expectations. We don't go out >>>> of our way to _try_ and break things most of the time. "without a >>>> deprecation process" is also reasonable wording. Feel free to adopt those >>>> words. >>>> >>>> Ideally we try to have discussion somewhere relevant when we _know_ >>>> we'd intentionally be removing support for something (for example of why: >>>> See the debacle that happened when dropping Solaris support was proposed). >>>> >>>> -gps >>>> >>>> >>>>> >>>>> -- >>>>> Marc-Andre Lemburg >>>>> eGenix.com >>>>> >>>>> Professional Python Services directly from the Experts (#1, Mar 14 >>>>> 2022) >>>>> >>> Python Projects, Coaching and Support ... >>>>> https://www.egenix.com/ >>>>> >>> Python Product Development ... >>>>> https://consulting.egenix.com/ >>>>> >>>>> ________________________________________________________________________ >>>>> >>>>> ::: 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/ >>>>> >>>>> _______________________________________________ >>>>> 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/STJAMJ45INJB2KDRMNDK6Y6REHZRAXTY/ >>>>> Code of Conduct: https://www.python.org/psf/codeofconduct/ >>>>> >>>>
_______________________________________________ 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/K7P3QK5AQIENQCXBSPQMBVUINZVDRYUM/ Code of Conduct: https://www.python.org/psf/codeofconduct/
