[python-committers] Re: Proposed tiered platform support

On 08/06/2022 21.21, Brett Cannon wrote: FYI there are now tier labels for the buildbots and the links have been added to the PEP. https://peps.python.org/pep-0011/#support-tiers Tier 2: https://buildbot.python.org/all/#/builders?tags=%2B3.x&t

[python-committers] Re: Proposed tiered platform support

FYI there are now tier labels for the buildbots and the links have been added to the PEP. https://peps.python.org/pep-0011/#support-tiers Tier 2: https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Btier-2 Tier 3: https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Btier-3 (Ti

[python-committers] Re: Proposed tiered platform support

On Fri, Apr 1, 2022 at 1:42 AM Victor Stinner wrote: > > On Fri, Apr 1, 2022 at 12:25 AM Brett Cannon wrote: > > powerpcle-linux-gnu glibc, clang > > This one has 2 core devs in the PR: "Petr Viktorin, Victor Stinner". Oh wait, "Petr Viktorin, Victor Stinner" are for gcc, and this is is for clan

[python-committers] Re: Proposed tiered platform support

On Fri, Apr 1, 2022 at 12:25 AM Brett Cannon wrote: > powerpcle-linux-gnu glibc, clang This one has 2 core devs in the PR: "Petr Viktorin, Victor Stinner". > s390x-linux-gnu glibc, gcc > s390x-linux-gnu glibc, clang > x86_64-unknown-freebsd BSD libc, cc (Victor is already listed) I started a ne

[python-committers] Re: Proposed tiered platform support

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-wind

[python-committers] Re: Proposed tiered platform support

On Tue, Mar 29, 2022 at 12:40 AM Anthony Baxter wrote: > I wonder if putting this into a PEP might be a little heavyweight in terms > of making adjustments to the platform triples and their priorities? I > perhaps think something that's a look aside table with a defined policy of > how to move va

[python-committers] Re: Proposed tiered platform support

I wonder if putting this into a PEP might be a little heavyweight in terms of making adjustments to the platform triples and their priorities? I perhaps think something that's a look aside table with a defined policy of how to move various triples up and down might work better? On Fri, 11 Mar 2022

[python-committers] Re: Proposed tiered platform support

On Mon, Mar 28, 2022 at 7:09 AM Petr Viktorin wrote: > On Fri, Mar 25, 2022 at 8:32 PM 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-

[python-committers] Re: Proposed tiered platform support

On Sat, Mar 26, 2022 at 10:11 AM Victor Stinner wrote: > On Fri, Mar 25, 2022 at 7:04 PM Brett Cannon wrote: > > > > 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``,

[python-committers] Re: Proposed tiered platform support

On Fri, Mar 25, 2022 at 1:18 PM Ned Deily wrote: > 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 cl

[python-committers] Re: Proposed tiered platform support

On 3/26/2022 5:11 PM, Victor Stinner wrote: * Buildbots run the test suite with "-u all" option. On Windows, Python is built in debug mode. * GHA uses "-u all,-cpu". On Windows, Python is built in release mode (I think that changed last change after the 3rd buildbot failure not catched by GHA but

[python-committers] Re: Proposed tiered platform support

On Fri, Mar 25, 2022 at 8:32 PM 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 > aarch64-linux-gnu glibc, clang (Victor is already l

[python-committers] Re: Proposed tiered platform support

On Fri, Mar 25, 2022 at 7:04 PM Brett Cannon wrote: > > 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 pra

[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-appl

[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-lin

[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 h

[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

[python-committers] Re: Proposed tiered platform support

Ok, I added myself on the PR. Victor ___ 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 archiv

[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/p

[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 -- python-committers@pytho

[python-committers] Re: Proposed tiered platform support

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

[python-committers] Re: Proposed tiered platform support

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 allow

[python-committers] Re: Proposed tiered platform support

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

[python-committers] Re: Proposed tiered platform support

On Mon, Mar 14, 2022 at 12:59 PM Christian Heimes wrote: > On 14/03/2022 19.37, Brett Cannon wrote: > > > > > > On Fri, Mar 11, 2022 at 5:04 PM Victor Stinner > > wrote: > > > > Hi Brett, > > > > You can put my name as Contact of all Fedora and RHEL platforms.

[python-committers] Re: Proposed tiered platform support

On 14/03/2022 19.37, Brett Cannon wrote: On Fri, Mar 11, 2022 at 5:04 PM Victor Stinner > wrote: Hi Brett, You can put my name as Contact of all Fedora and RHEL platforms. Note: Fedora "Rawhide" is the rolling release and it's common that these bu

[python-committers] Re: Proposed tiered platform support

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." an

[python-committers] Re: Proposed tiered platform support

On Fri, Mar 11, 2022 at 5:04 PM Victor Stinner wrote: > Hi Brett, > > You can put my name as Contact of all Fedora and RHEL platforms. > > Note: Fedora "Rawhide" is the rolling release and it's common that > these buildbots are broken by kernel, compiler or glibc updates, > rather than actual Pyt

[python-committers] Re: Proposed tiered platform support

On Sat, Mar 12, 2022 at 5:29 AM Marc-Andre Lemburg wrote: > On 11.03.2022 19:26, Brett Cannon wrote: > > > > On Fri, Mar 11, 2022 at 1:18 AM Marc-Andre Lemburg wrote: > >> I think the list is missing some important platforms which we do >> support (looking at configure): >> >> * Linux on 32-bit

[python-committers] Re: Proposed tiered platform support

On Fri, Mar 11, 2022 at 12:37 PM Gregory P. Smith wrote: > > On Fri, Mar 11, 2022 at 10:45 AM Brett Cannon wrote: > >> >> On Fri, Mar 11, 2022 at 9:16 AM Paul Moore wrote: >> >>> On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg wrote: >>> > >>> > On 11.03.2022 17:42, Zachary Ware wrote: >>> >

[python-committers] Re: Proposed tiered platform support

> On 11 Mar 2022, at 00:35, Brett Cannon wrote: > > I brought this up on python-dev at > https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ > >

[python-committers] Re: Proposed tiered platform support

On 11. 03. 22 19:30, Brett Cannon wrote: On Fri, Mar 11, 2022 at 1:26 AM Petr Viktorin > wrote: On 11. 03. 22 0:35, Brett Cannon wrote: > I brought this up on python-dev at > https://mail.python.org/archives/list/python-...@python.org/thread/ZPBS

[python-committers] Re: Proposed tiered platform support

On 11.03.2022 19:26, Brett Cannon wrote: > > > On Fri, Mar 11, 2022 at 1:18 AM Marc-Andre Lemburg > wrote: > > I think the list is missing some important platforms which we do > support (looking at configure): > > * Linux on 32-bit ARM platforms, e.g. for Raspbe

[python-committers] Re: Proposed tiered platform support

Hi Brett, You can put my name as Contact of all Fedora and RHEL platforms. Note: Fedora "Rawhide" is the rolling release and it's common that these buildbots are broken by kernel, compiler or glibc updates, rather than actual Python regressions. Time to time, it detects real Python regressions. T

[python-committers] Re: Proposed tiered platform support

On Fri, Mar 11, 2022 at 10:45 AM Brett Cannon wrote: > > On Fri, Mar 11, 2022 at 9:16 AM Paul Moore wrote: > >> On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg wrote: >> > >> > On 11.03.2022 17:42, Zachary Ware wrote: >> > > >> > > - Only code which either supports a higher-tier platform or is

[python-committers] Re: Proposed tiered platform support

On Fri, Mar 11, 2022 at 9:16 AM Paul Moore wrote: > On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg wrote: > > > > On 11.03.2022 17:42, Zachary Ware wrote: > > > > > > - Only code which either supports a higher-tier platform or is a > general improvement may be checked in. > > > > My understand

[python-committers] Re: Proposed tiered platform support

On Fri, Mar 11, 2022 at 8:43 AM Zachary Ware wrote: > On Fri, Mar 11, 2022 at 7:45 AM Marc-Andre Lemburg wrote: > > If there are people in the community who wish to provide support for > > these platforms, I don't see a reason not to keep them in a tier 4. > > Such platforms would not be support

[python-committers] Re: Proposed tiered platform support

On Fri, Mar 11, 2022 at 1:38 AM Christian Heimes wrote: > On 11/03/2022 00.35, Brett Cannon wrote: > > I brought this up on python-dev at > > > https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ > > < > https://mail.python.org/archives/list/python

[python-committers] Re: Proposed tiered platform support

On Fri, Mar 11, 2022 at 1:26 AM Petr Viktorin wrote: > On 11. 03. 22 0:35, Brett Cannon wrote: > > I brought this up on python-dev at > > > https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ > > < > https://mail.python.org/archives/list/python-...

[python-committers] Re: Proposed tiered platform support

On Fri, Mar 11, 2022 at 1:18 AM Marc-Andre Lemburg wrote: > I think the list is missing some important platforms which we do > support (looking at configure): > > * Linux on 32-bit ARM platforms, e.g. for Raspberry Pis > * Linux on Android > * AIX > * Cygwin > * NetBSD/OpenBSD > * musl instead of

[python-committers] Re: Proposed tiered platform support

On 11/03/2022 18.08, Marc-Andre Lemburg wrote: All other platforms === - Only code which either supports a higher-tier platform or is a general improvement may be checked in. My understanding of that sentence is: PRs which target platforms not listed in PEP 11 may not be check

[python-committers] Re: Proposed tiered platform support

On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg wrote: > > On 11.03.2022 17:42, Zachary Ware wrote: > > > > - Only code which either supports a higher-tier platform or is a general > > improvement may be checked in. > > My understanding of that sentence is: PRs which target platforms > not liste

[python-committers] Re: Proposed tiered platform support

On 11.03.2022 17:42, Zachary Ware wrote: > On Fri, Mar 11, 2022 at 7:45 AM Marc-Andre Lemburg wrote: >> If there are people in the community who wish to provide support for >> these platforms, I don't see a reason not to keep them in a tier 4. >> Such platforms would not be supported by the core t

[python-committers] Re: Proposed tiered platform support

On Fri, Mar 11, 2022 at 7:45 AM Marc-Andre Lemburg wrote: > If there are people in the community who wish to provide support for > these platforms, I don't see a reason not to keep them in a tier 4. > Such platforms would not be supported by the core team and don't > necessarily need a buildbot (e

[python-committers] Re: Proposed tiered platform support

On 11.03.2022 13:52, Christian Heimes wrote: > On 11/03/2022 10.18, Marc-Andre Lemburg wrote: >> I think the list is missing some important platforms which we do >> support (looking at configure): >> >> * Linux on 32-bit ARM platforms, e.g. for Raspberry Pis >> * Linux on Android >> * AIX >> * Cygw

[python-committers] Re: Proposed tiered platform support

On 11/03/2022 10.18, Marc-Andre Lemburg wrote: I think the list is missing some important platforms which we do support (looking at configure): * Linux on 32-bit ARM platforms, e.g. for Raspberry Pis * Linux on Android * AIX * Cygwin * NetBSD/OpenBSD * musl instead of glibc for Linux, e.g. for A

[python-committers] Re: Proposed tiered platform support

On 11/03/2022 00.35, Brett Cannon wrote: I brought this up on python-dev at https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ , and the feedb

[python-committers] Re: Proposed tiered platform support

On 11. 03. 22 0:35, Brett Cannon wrote: I brought this up on python-dev at https://mail.python.org/archives/list/python-...@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ , and the feedba

[python-committers] Re: Proposed tiered platform support

I think the list is missing some important platforms which we do support (looking at configure): * Linux on 32-bit ARM platforms, e.g. for Raspberry Pis * Linux on Android * AIX * Cygwin * NetBSD/OpenBSD * musl instead of glibc for Linux, e.g. for Alpine images In general, I believe we should add