[python-committers] Re: Proposed tiered platform support
You wrote that you want at least 2 core devs responsible for each tier 1 platform. I didn't understand if this requirement is also for Tier 2. Who are these core devs? Is there a list? Victor ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/D76GVZE5SIWXF57XXU2KISFRM7EGS5OK/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Proposed tiered platform support
On 25. 03. 22 11:43, Victor Stinner wrote: You wrote that you want at least 2 core devs responsible for each tier 1 platform. I didn't understand if this requirement is also for Tier 2. Who are these core devs? Is there a list? The list will be in the PEP. Add yourself at https://github.com/python/peps/pull/2442 as a review suggestion. That PR also has the current text of the proposal. ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/LW3IDZMHWNOMKCGADU5KBA3WNR5FRCHT/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Proposed tiered platform support
Ok, I added myself on the PR. Victor ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/EQ63U24M6VM736WAZ3F2A2U6O6WKHH3C/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Proposed tiered platform support
I dislike the Tier 1 rule "All core developers are responsible to keep these platforms, and thus ``main``, working." In my experience, "Everyone is reponsible" means in practice "nobody is responsible". IMO you must also put two names in front of each platform. Otherwise, nobody will fix them when it will be broken, and the best that we will be able to do is to just revert the change breaking the CI which prevents adding new features just because nobody wants to fix the CI. Sometimes, a broken CI is unrelated to a Python change. Things break, *all the time*, for many various reasons including vacuum cleaners (*)! (*) https://mail.python.org/archives/list/[email protected]/message/27OMCAPT6TCZUKAXBTL3X3PCKLXCMS5J/ Victor ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/HTB6JJBENYTI32UCQUXCZQLBL2YBCC4T/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Proposed tiered platform support
On Fri, Mar 25, 2022 at 4:23 AM Victor Stinner wrote: > I dislike the Tier 1 rule "All core developers are responsible to keep > these platforms, and thus ``main``, working." > > In my experience, "Everyone is reponsible" means in practice "nobody > is responsible". I don't think that applies here as you shouldn't even be merging a PR if it breaks CI for these platforms. And if CI isn't good enough then we should fix that. If you still want a point of contact for those platforms then we can talk about that, but I wouldn't expect the listed folks to be as critical on those platforms to keep things functioning like they are for a tier 2 being supported by a buildbot post-merge. Or put another way, tier 1 platforms are so critical we can't be expected to be dropped if someone isn't being responsive to questions, unlike tier 2 where we would probably drop a platform if folks weren't responsive enough. > IMO you must also put two names in front of each > platform. Otherwise, nobody will fix them when it will be broken, and > the best that we will be able to do is to just revert the change > breaking the CI which prevents adding new features just because nobody > wants to fix the CI. > > Sometimes, a broken CI is unrelated to a Python change. Things break, > *all the time*, for many various reasons including vacuum cleaners > (*)! > But tier 1 is the CI we run on PRs, not in the Buildbot fleet. > > (*) > https://mail.python.org/archives/list/[email protected]/message/27OMCAPT6TCZUKAXBTL3X3PCKLXCMS5J/ > > Victor > ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/UTNDM3V4VM7QCYFISX4XBSJ3MP7CO2P6/ Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Re: Proposed tiered platform support
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 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 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 wrote: >> >>> >>> >>> On Mon, Mar 14, 2022 at 11:43 AM Marc-Andre Lemburg >>> 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 und
[python-committers] Re: Proposed tiered platform support
On Mar 25, 2022, at 15:32, Brett Cannon 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: > • arch64-apple-darwin clang [...] I added this comment to the PR: If x86_64-apple-darwin is a Tier 1 platform, then this must be as well. As of today, nearly all Macs being manufactured by Apple are of this architecture (i.e. Apple Silicon) and Apple has made clear that the few remaining legacy Intel-based Macs still being offered will be replaced in the near future (likely by the end of 2022). So, eventually x86_64-apple-darwin will fade in importance as older Macs are retired but that will take many years. -- Ned Deily [email protected] -- [] ___ python-committers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/IXZIHXFZJM27YYV2JNYJYWNLZWPZT3V6/ Code of Conduct: https://www.python.org/psf/codeofconduct/
