[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Marc-Andre Lemburg 
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 a 4th tier for platforms supported
by interested parties outside the core team. Those would be supported on
a best effort basis by the parties and we'd point to the teams for
support. Some of the above platforms would likely have to go into
this tier.

It would also be nice to add a column to the table which shows
the platforms for which binaries are built during the release and
which are source only. At the moment, only Windows and
macOS platforms have official binaries.


On 11.03.2022 00:35, Brett Cannon wrote:
> I brought this up on python-dev at
> https://mail.python.org/archives/list/[email protected]/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/
> , and the feedback seemed supportive. As such, I am bringing a draft of what 
> I'm
> thinking will go into PEP 11 with a bunch of `XXX` placeholders for people to
> help me fill in to see how this will look overall.
> 
> For any platform(s) you support, please reply with any relevant details that
> should be added to the relevant tables below. Once I have these details I will
> loop back with the proposed update to PEP 11 and make sure everyone is still 
> on
> board with the proposal.
> 
> =
> Tiers
> =
> 
> Tier 1
> ==
> 
> - `Test suite failures
> `__
> 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 working.
> - Promotion of this tier requires consensus/SC approval.
> 
> === =
> Target Triple       Notes
> === =
> i686-windows-msvc
> x86_64-windows-msvc
> x86_64-apple-darwin macOS 11
> x86_64-linux-gnu    glibc 2.31 |ubuntu-20_01|_
> === =
> 
> .. [ubuntu-20_01] https://launchpad.net/ubuntu/+source/glibc/2.31-0ubuntu9.4
> 
> 
> Tier 2
> ==
> 
> - Must have a stable buildbot.
> - At least **two** core developers are signed up to support the platform.
> - Changes which break any of these platforms are to be reverted within 24 
> hours.
> - Failures of these platforms block a release.
> - Promotion of this tier requires consensus/SC approval.
> 
> == ==
> == 
> Target Triple          Notes                      Buildbot                    
>   
>                 Contacts
> == ==
> == 
> aarch64-apple-darwin   XXX                      
>  https://buildbot.python.org/all/#/builders/725 XXX
> aarch64-linux-gnu      glibc XXX [fedora-stable]_
> https://buildbot.python.org/all/#/builders/125 XXX
>                        glibc 2.28 [RHEL8]_      
>  https://buildbot.python.org/all/#/builders/529 XXX
> aarch64-windows-msvc   XXX                      
>  https://buildbot.python.org/all/#/builders/729 XXX
> powerpc64-linux-gnu    glibc XXX                
>  https://buildbot.python.org/all/#/builders/237 XXX
> powerpcle-linux-gnu    glibc XXX                
>  https://buildbot.python.org/all/#/builders/90  XXX
> s309x-linux-gnu        glibc XXX                
>  https://buildbot.python.org/all/#/builders/223 XXX
>                        glibc 2.28 [RHEL8]_      
>  https://buildbot.python.org/all/#/builders/509 XXX
>                        glibc 2.17 [RHEL7]_      
>  https://buildbot.python.org/all/#/builders/179 XXX
> x86_64-linux-gnu       glibc 2.17 [RHEL7]_      
>  https://buildbot.python.org/all/#/builders/15  XXX
> x86_64-unknown-freebsd XXX                      
>  https://buildbot.python.org/all/#/builders/172 XXX
> == ==
> == 
> 
> .. [fedora-stable] XXX
> .. [RHEL8] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_8
> .. [RHEL7]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.0_release_notes/sect-red_hat_enterprise_linux-7.0_release_notes-compiler_and_tools-glibc
> 
> 
> Tier 3
> ==
> 
> - Must have a stable buildbot.
> - Code may be checked into ``main`` for the platform.
> - At least **one** core developer is signed up to support the platform.
> - Test failures do **not** block releases.
> - Promotion to this tier is self-service.
> 
> = ==
> == 
> Target Triple             Notes                      Buildbot                 
>  
>                     Contacts
> = =

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Petr Viktorin 

On 11. 03. 22 0:35, Brett Cannon wrote:
I brought this up on python-dev at 
https://mail.python.org/archives/list/[email protected]/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ 
 
, and the feedback seemed supportive. As such, I am bringing a draft of 
what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders 
for people to help me fill in to see how this will look overall.


For any platform(s) you support, please reply with any relevant details 
that should be added to the relevant tables below. Once I have these 
details I will loop back with the proposed update to PEP 11 and make 
sure everyone is still on board with the proposal.


=
Tiers
=

Tier 1
==

- `Test suite failures 
>`__ 
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 working.


What does this mean?
I can not merge a change if it doesn't pass macOS CI, but I don't have a 
macOS system, so I can't really diagnose and fix macOS bugs.



- Promotion of this tier requires consensus/SC approval.

=== =
Target Triple       Notes
=== =
i686-windows-msvc


What's the supported version of Windows?


x86_64-windows-msvc
x86_64-apple-darwin macOS 11
x86_64-linux-gnu    glibc 2.31 |ubuntu-20_01|_


Would it be better to say “whatever GitHub Actions has” in the long-term 
docs, and put the specific version in the docs rather than in the PEP?




[...]> All other platforms

===

- Only code which either supports a higher-tier platform or is a general 
improvement may be checked in.


I'm worried about going from this to tier 3.
How do you get to a platform's buildbot being stable if you can't merge 
code for it?


___
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/XY2HMEEM46R5QI6C3A3NL4ICQ7LVYC2W/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Christian Heimes 

On 11/03/2022 00.35, Brett Cannon wrote:
I brought this up on python-dev at 
https://mail.python.org/archives/list/[email protected]/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ 
 
, and the feedback seemed supportive. As such, I am bringing a draft of 
what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders 
for people to help me fill in to see how this will look overall.


For any platform(s) you support, please reply with any relevant details 
that should be added to the relevant tables below. Once I have these 
details I will loop back with the proposed update to PEP 11 and make 
sure everyone is still on board with the proposal.



A few remarks:

autoconf, GCC, and Debian call it "Target Triplet". Clang and Rust use 
"Target Triple". Should we stick with the clang name or use the GCC name?


Target triplets are machine-vendor-os. They come in short, normalized 
form and in long, extended form. The normalized form often omits the 
vendor field. Your document has both long and short forms. 
"wasm32-unknown-emscripten" is extended form for "wasm32-emscripten", 
while "x86_64-windows-msvc" is the short form of 
"x86_64-pc-windows-msvc". I recommend to stick to one convention.


By the way config.guess script and gcc can dump the current triplet. The 
config.sub script can be used to normalize and validate a triplet (does 
not work for MSVC). The output of config.guess is more specific than the 
gcc machine info. Here is a dump from my RPi:


$ ./config.guess
armv7l-unknown-linux-gnueabihf
$ gcc -dumpmachine
arm-linux-gnueabih
$ ./config.sub arm-linux-gnueabihf
arm-unknown-linux-gnueabihf


= == 
== 
Target Triple             Notes                      Buildbot   
                             Contacts
= == 
== 
wasm32-unknown-emscripten XXX                        XXX 
                            Brett Cannon, Christian Heimes
wasm32-unknown-wasi       XXX                        XXX 
                            Brett Cannon, Christian Heimes
= == 
== 


It's a bit premature to add wasm32-wasi. Python doesn't even compile on 
WASI yet.


Christian
___
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/XVVSUA4MGOSO7UXY4ISSGGSYKPUXPTQ4/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Christian Heimes 

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 Alpine images


These platforms are missing on purpose. None of these platforms have a 
stable buildbot and tests are failing on most of them.


- Greg is running an unstable buildbot on an RPi at home, so RPi may fit 
into Tier 3.


- Alpine / musl is not supported, because our test suite is failing due 
to bugs and missing features in musl libc.


- NetBSD and OpenBSD are in a similar state as Alpine: no stable 
buildbot and AFAIK tests are failing


- Android is no longer actively maintained

- Cygwin and MinGW are officially unsupported, see bpo-45537 and bpo-45538

___
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/IQ7X75RG5DFMUAHCNZFEJEH5DOEJPN7K/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Marc-Andre Lemburg 
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
>> * Cygwin
>> * NetBSD/OpenBSD
>> * musl instead of glibc for Linux, e.g. for Alpine images
> 
> These platforms are missing on purpose. None of these platforms have a stable
> buildbot and tests are failing on most of them.
> 
> - Greg is running an unstable buildbot on an RPi at home, so RPi may fit into
> Tier 3.
> 
> - Alpine / musl is not supported, because our test suite is failing due to 
> bugs
> and missing features in musl libc.
> 
> - NetBSD and OpenBSD are in a similar state as Alpine: no stable buildbot and
> AFAIK tests are failing
> 
> - Android is no longer actively maintained
>
> - Cygwin and MinGW are officially unsupported, see bpo-45537 and bpo-45538

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 (even though it would be good to have them).

I find it problematic that the way Brett has written the proposal essentially
means that we will not accept any PRs to help support platforms which
are not listed in the tables. Could be that I misinterpreted his writeup,
though.

Esp. Android and possibly iOS are platforms which Python should be
targeting in the future, since the story for Python on those platforms
currently is pretty. We shouldn't make it harder to eventually gain
such support and hopefully find new core devs who can maintain them
to become fully supported.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Mar 11 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 -- [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/KEZNLSJ7KSAUHZ5KNEBOJT7Y5FC6D5BJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Zachary Ware 
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 (even though it would be good to have them).
>
> I find it problematic that the way Brett has written the proposal essentially
> means that we will not accept any PRs to help support platforms which
> are not listed in the tables. Could be that I misinterpreted his writeup,
> though.
>
> Esp. Android and possibly iOS are platforms which Python should be
> targeting in the future, since the story for Python on those platforms
> currently is pretty. We shouldn't make it harder to eventually gain
> such support and hopefully find new core devs who can maintain them
> to become fully supported.

As I understand it, the idea here is that if there is no core dev for
a platform, it's not actually supported in a practical sense
regardless of our official policy or lack thereof.  The policy Brett
is proposing just makes that explicit and gives us something to point
to when someone comes up with a patch to support PDP-11 or when
someone's patch for Android breaks Windows.  I don't think we'll wind
up with tier support police; if a core dev wants to take
responsibility for a patch for a platform that is not tier 3 or above
they can still do that, but if it breaks things for a supported
platform it will be reverted.

If there is serious support for a non-tiered platform, all it takes is
a buildbot and either an existing core dev to sign up to be the
maintainer or for us to vote in a maintainer, and then it can be a
tier 3 platform.  If there's not someone actively maintaining it and
the tests regularly being run on it, we can't realistically claim to
support it anyway.

I don't see much value in a tier 4: all other platforms that aren't
tier 3 or above are tier 4.  We could link to a wiki page for where
one might find links to support communities for non-tiered platforms,
but I expect such a list would bitrot at a rate that makes it not
worth including in the official tier list, whether by those
communities fading away or the platform being promoted to tier 3.


On Thu, Mar 10, 2022 at 5:36 PM Brett Cannon  wrote:
> Tier 1
> ==
>
> - `Test suite failures 
> `__
>  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 working.
> - Promotion of this tier requires consensus/SC approval.

Should tier 1 require pre-merge CI?  We can currently do that, but
promoting a platform that's not provided by GHA could require
significant workflow changes.

> - Must have a stable buildbot.

I have concerns about the term "stable buildbot".  Until now, the
"stable"/"unstable" tags on buildbots have been the closest thing
we've had to a platform support policy and we've treated failures on a
"stable" buildbot to be release blockers (for the most part).  With a
proper platform support policy, "stable"/"unstable" should become a
description of the reliability of the particular worker machine to
provide an accurate representation of the state of the tests on the
platform rather than whether the tests usually pass, but I'm worried
about confusion from the changing meaning of those labels.
___
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/I6OHDE5OAK3OIF7ZPRHK573H4YIZ5EOM/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Marc-Andre Lemburg 
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 team and don't
>> necessarily need a buildbot (even though it would be good to have them).
>>
>> I find it problematic that the way Brett has written the proposal essentially
>> means that we will not accept any PRs to help support platforms which
>> are not listed in the tables. Could be that I misinterpreted his writeup,
>> though.
>>
>> Esp. Android and possibly iOS are platforms which Python should be
>> targeting in the future, since the story for Python on those platforms
>> currently is pretty. We shouldn't make it harder to eventually gain
>> such support and hopefully find new core devs who can maintain them
>> to become fully supported.
> 
> As I understand it, the idea here is that if there is no core dev for
> a platform, it's not actually supported in a practical sense
> regardless of our official policy or lack thereof.  The policy Brett
> is proposing just makes that explicit and gives us something to point
> to when someone comes up with a patch to support PDP-11 or when
> someone's patch for Android breaks Windows.  I don't think we'll wind
> up with tier support police; if a core dev wants to take
> responsibility for a patch for a platform that is not tier 3 or above
> they can still do that, but if it breaks things for a supported
> platform it will be reverted.
> 
> If there is serious support for a non-tiered platform, all it takes is
> a buildbot and either an existing core dev to sign up to be the
> maintainer or for us to vote in a maintainer, and then it can be a
> tier 3 platform.  If there's not someone actively maintaining it and
> the tests regularly being run on it, we can't realistically claim to
> support it anyway.
> 
> I don't see much value in a tier 4: all other platforms that aren't
> tier 3 or above are tier 4.  We could link to a wiki page for where
> one might find links to support communities for non-tiered platforms,
> but I expect such a list would bitrot at a rate that makes it not
> worth including in the official tier list, whether by those
> communities fading away or the platform being promoted to tier 3.

The important bit here is this part:

> 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 checked in.

IMO, it doesn't make sense to prohibit support code in the
code base, if there is community interest in this. By dropping
that line, we wouldn't have a problem and also don't
need to list platforms in a tier 4 section, since it's still
possible to add support in the main code base, without having
a core dev maintain it.

PEP 11 would then just list platforms publicly that the core
dev team can support; not implicitly exclude platforms which we
cannot support, but for which there is community interest and
support available.

E.g. Android support was even funded by the PSF recently. Why
would we want to remove that support from the code base again,
just because we don't have a core dev maintaining it ?

Also note that the stdlib does in fact support other Python
implementations reusing (parts of) it, e.g. Jython, PyPy and
IronPython. Again, without core devs backing these.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Mar 11 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 -- [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/V6HRBHKCD7R2K2IVZO3SIHXOGQO2J5P7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Paul Moore 
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 listed in PEP 11 may not be checked in.
>
> IMO, it doesn't make sense to prohibit support code in the
> code base, if there is community interest in this. By dropping
> that line, we wouldn't have a problem and also don't
> need to list platforms in a tier 4 section, since it's still
> possible to add support in the main code base, without having
> a core dev maintain it.

I agree, the simplest solution here seems to be just to not include
that line. We can still push back on PRs for unsupported platforms if
we want, we just won't have a policy that *requires* us to do so.

If it turns out that leaving it to core devs' judgement is a problem,
we can agree a policy with some concrete examples to inform us.
Paul
___
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/YICN5XDHHH4YNU5FDXLAKOHA25Y6U5UP/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Python Language Summit at PyCon 2022 in Salt Lake City

2022-03-11 Thread Mariatta 
We're excited to announce that the signups for Python Language Summit at
PyCon 2022 are now open.

Full details at: https://us.pycon.org/2022/events/language-summit/

After two years of virtual/online summit, we will be returning to in-person
format. We will be following the health and safety guidelines at PyCon US:
https://us.pycon.org/2022/attend/health-safety-guidelines/

*TL;DR*

When: Wednesday, April 27, 2022
Where: Salt Palace Convention Center, room TBD

Sign up to attend:  https://forms.gle/CS8B6wJdcaN3rtWV8
 (closes March 25 th, 2022 AoE)
Sign up to discuss a topic: https://forms.gle/LAFE6TTYi15jL5RaA (closes
March 25th, 2022 AoE)

*Who can attend*

We welcome Python core developers and triage team members, active core
contributors to Python and alternative Python implementations, and anyone
else who has a topic to discuss with core developers.

*Who can propose a discussion topic*

If you have discussion items; seeking consensus; awaiting decision on a
PEP; needing help with your core dev work; or have specific questions that
need answers from core developers, please submit a proposal. According to
feedback, our audience prefers more discussions and shorter talks.

In your proposal, please include:
- why is this topic relevant to the core developers
- what is needed from core developers out of this topic

This year's event will be covered by Alex Waygood. Detailed summary of the
event will be published at The PSF's Blog.

*Is this event recorded? Can I watch the livestream?*

No, there will be no recording and no livestream available. If you'd like
to participate in discussions, please sign up to attend. If you'd like to
listen in, please wait for Alex's blog posts after the summit.

Thank you,

Mariatta, Łukasz, & Senthil
___
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/OQ2UJCXV42FERRQAAS7IVPERJBAZIMHC/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Christian Heimes 

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 checked in.

IMO, it doesn't make sense to prohibit support code in the
code base, if there is community interest in this. By dropping
that line, we wouldn't have a problem and also don't
need to list platforms in a tier 4 section, since it's still
possible to add support in the main code base, without having
a core dev maintain it.


Community interest is not sufficient. A supported platform needs active 
engagement and contributions by the community or vendor. At a bare 
minimum a platform needs a core developer, who is interested in the 
platform, and a credible statement, that a buildbot will be provided in 
the near future.


Please note that the text of the rule is "may be checked in", not "core 
devs are forbidden to check in". There is a gray area for trivial 
patches or aspiring platforms. The rule gives us an easy way to refuse 
patches that cannot be tested. It also gives vendors a list of 
requirements as well as motivation to contribute buildbots.


Christian
___
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/M2P5ZTL2WDPK2BAL46YQUS5VQDJ65PVH/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Brett Cannon 
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 glibc for Linux, e.g. for Alpine images
>

I went off of what we have stable buildbots for. If we want to either
loosen the tier 3 requirement for a Buildbot or introduce a historical tier
4 we can. But, for instance, do any of us if AIX support actually works
right now?


>
> In general, I believe we should add a 4th tier for platforms supported
> by interested parties outside the core team. Those would be supported on
> a best effort basis by the parties and we'd point to the teams for
> support. Some of the above platforms would likely have to go into
> this tier.
>

My worry with that is having to try and keep that information up-to-date.
Plus I would prefer to not have a PEP listing platforms where the status of
the support is 🤷.


>
> It would also be nice to add a column to the table which shows
> the platforms for which binaries are built during the release and
> which are source only. At the moment, only Windows and
> macOS platforms have official binaries.
>

I was actually explicitly asked by someone who is part of doing releases
*not* to list installers as they would prefer they not be viewed as
required to exist.

-Brett


>
>
> On 11.03.2022 00:35, Brett Cannon wrote:
> > I brought this up on python-dev at
> >
> https://mail.python.org/archives/list/[email protected]/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/
> > , and the feedback seemed supportive. As such, I am bringing a draft of
> what I'm
> > thinking will go into PEP 11 with a bunch of `XXX` placeholders for
> people to
> > help me fill in to see how this will look overall.
> >
> > For any platform(s) you support, please reply with any relevant details
> that
> > should be added to the relevant tables below. Once I have these details
> I will
> > loop back with the proposed update to PEP 11 and make sure everyone is
> still on
> > board with the proposal.
> >
> > =
> > Tiers
> > =
> >
> > Tier 1
> > ==
> >
> > - `Test suite 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 working.
> > - Promotion of this tier requires consensus/SC approval.
> >
> > === =
> > Target Triple   Notes
> > === =
> > i686-windows-msvc
> > x86_64-windows-msvc
> > x86_64-apple-darwin macOS 11
> > x86_64-linux-gnuglibc 2.31 |ubuntu-20_01|_
> > === =
> >
> > .. [ubuntu-20_01]
> https://launchpad.net/ubuntu/+source/glibc/2.31-0ubuntu9.4
> >
> >
> > Tier 2
> > ==
> >
> > - Must have a stable buildbot.
> > - At least **two** core developers are signed up to support the platform.
> > - Changes which break any of these platforms are to be reverted within
> 24 hours.
> > - Failures of these platforms block a release.
> > - Promotion of this tier requires consensus/SC approval.
> >
> > == ==
> > == 
> > Target Triple  Notes  Buildbot
>
> > Contacts
> > == ==
> > == 
> > aarch64-apple-darwin   XXX
> >  https://buildbot.python.org/all/#/builders/725 XXX
> > aarch64-linux-gnu  glibc XXX [fedora-stable]_
> > https://buildbot.python.org/all/#/builders/125 XXX
> >glibc 2.28 [RHEL8]_
> >  https://buildbot.python.org/all/#/builders/529 XXX
> > aarch64-windows-msvc   XXX
> >  https://buildbot.python.org/all/#/builders/729 XXX
> > powerpc64-linux-gnuglibc XXX
> >  https://buildbot.python.org/all/#/builders/237 XXX
> > powerpcle-linux-gnuglibc XXX
> >  https://buildbot.python.org/all/#/builders/90  XXX
> > s309x-linux-gnuglibc XXX
> >  https://buildbot.python.org/all/#/builders/223 XXX
> >glibc 2.28 [RHEL8]_
> >  https://buildbot.python.org/all/#/builders/509 XXX
> >glibc 2.17 [RHEL7]_
> >  https://buildbot.python.org/all/#/builders/179 XXX
> > x86_64-linux-gnu   glibc 2.17 [RHEL7]_
> >  https://buildbot.python.org/all/#/builders/15  XXX
> > x86_64-unknown-freebsd XXX
> >  https://buildbot.python.org/all/#/builders/172 XXX
> > == ==
> > == 
> >
> > .. [fedora-stable] XXX
> > .. [RHEL8] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_8
> > .. [RHEL7]
> >
> https://access.redhat.com/docum

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Brett Cannon 
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/[email protected]/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/
> > <
> https://mail.python.org/archives/list/[email protected]/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/>
>
> > , and the feedback seemed supportive. As such, I am bringing a draft of
> > what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders
> > for people to help me fill in to see how this will look overall.
> >
> > For any platform(s) you support, please reply with any relevant details
> > that should be added to the relevant tables below. Once I have these
> > details I will loop back with the proposed update to PEP 11 and make
> > sure everyone is still on board with the proposal.
> >
> > =
> > Tiers
> > =
> >
> > Tier 1
> > ==
> >
> > - `Test suite failures
> > <
> https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted
> > <
> 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 working.
>
> What does this mean?
> I can not merge a change if it doesn't pass macOS CI, but I don't have a
> macOS system, so I can't really diagnose and fix macOS bugs.
>

Do you merge PRs today that don't pass CI on macOS?


>
> > - Promotion of this tier requires consensus/SC approval.
> >
> > === =
> > Target Triple   Notes
> > === =
> > i686-windows-msvc
>
> What's the supported version of Windows?
>
> > x86_64-windows-msvc
> > x86_64-apple-darwin macOS 11
> > x86_64-linux-gnuglibc 2.31 |ubuntu-20_01|_
>
> Would it be better to say “whatever GitHub Actions has” in the long-term
> docs, and put the specific version in the docs rather than in the PEP?
>

Perhaps; I was tempted to do that, but Christian requested the triples.


>
>
>
> [...]> All other platforms
> > ===
> >
> > - Only code which either supports a higher-tier platform or is a general
> > improvement may be checked in.
>
> I'm worried about going from this to tier 3.
> How do you get to a platform's buildbot being stable if you can't merge
> code for it?
>


You could develop code outside of the CPython repo until the platform is
ready to be supported.

Would you propose to drop the Buildbot requirement for tier 3 or introduce
a tier 4?
___
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/E43OQIOZ745MZFAZTPUJEKYMVWOUH2EI/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Brett Cannon 
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/[email protected]/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/
> > <
> https://mail.python.org/archives/list/[email protected]/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/>
>
> > , and the feedback seemed supportive. As such, I am bringing a draft of
> > what I'm thinking will go into PEP 11 with a bunch of `XXX` placeholders
> > for people to help me fill in to see how this will look overall.
> >
> > For any platform(s) you support, please reply with any relevant details
> > that should be added to the relevant tables below. Once I have these
> > details I will loop back with the proposed update to PEP 11 and make
> > sure everyone is still on board with the proposal.
>
>
> A few remarks:
>
> autoconf, GCC, and Debian call it "Target Triplet". Clang and Rust use
> "Target Triple". Should we stick with the clang name or use the GCC name?
>
> Target triplets are machine-vendor-os. They come in short, normalized
> form and in long, extended form. The normalized form often omits the
> vendor field. Your document has both long and short forms.
> "wasm32-unknown-emscripten" is extended form for "wasm32-emscripten",
> while "x86_64-windows-msvc" is the short form of
> "x86_64-pc-windows-msvc". I recommend to stick to one convention.
>

Whatever you all tell me. 😉 I did the best I could on what the Rust tiers
listed and what I know.


>
> By the way config.guess script and gcc can dump the current triplet. The
> config.sub script can be used to normalize and validate a triplet (does
> not work for MSVC). The output of config.guess is more specific than the
> gcc machine info. Here is a dump from my RPi:
>
> $ ./config.guess
> armv7l-unknown-linux-gnueabihf
> $ gcc -dumpmachine
> arm-linux-gnueabih
> $ ./config.sub arm-linux-gnueabihf
> arm-unknown-linux-gnueabihf
>
>
> > = ==
> > == 
> > Target Triple Notes  Buildbot
> >  Contacts
> > = ==
> > == 
> > wasm32-unknown-emscripten XXXXXX
> > Brett Cannon, Christian Heimes
> > wasm32-unknown-wasi   XXXXXX
> > Brett Cannon, Christian Heimes
> > = ==
> > == 
>
> It's a bit premature to add wasm32-wasi. Python doesn't even compile on
> WASI yet.
>

👍


>
> Christian
>
___
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/YXEN4GW3GTJUHULIOY45PHSKGNYHAM4E/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Brett Cannon 
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 supported by the core team and don't
> > necessarily need a buildbot (even though it would be good to have them).
> >
> > I find it problematic that the way Brett has written the proposal
> essentially
> > means that we will not accept any PRs to help support platforms which
> > are not listed in the tables. Could be that I misinterpreted his writeup,
> > though.
> >
> > Esp. Android and possibly iOS are platforms which Python should be
> > targeting in the future, since the story for Python on those platforms
> > currently is pretty. We shouldn't make it harder to eventually gain
> > such support and hopefully find new core devs who can maintain them
> > to become fully supported.
>
> As I understand it, the idea here is that if there is no core dev for
> a platform, it's not actually supported in a practical sense
> regardless of our official policy or lack thereof.  The policy Brett
> is proposing just makes that explicit and gives us something to point
> to when someone comes up with a patch to support PDP-11 or when
> someone's patch for Android breaks Windows.  I don't think we'll wind
> up with tier support police; if a core dev wants to take
> responsibility for a patch for a platform that is not tier 3 or above
> they can still do that, but if it breaks things for a supported
> platform it will be reverted.
>
> If there is serious support for a non-tiered platform, all it takes is
> a buildbot and either an existing core dev to sign up to be the
> maintainer or for us to vote in a maintainer, and then it can be a
> tier 3 platform.  If there's not someone actively maintaining it and
> the tests regularly being run on it, we can't realistically claim to
> support it anyway.
>
> I don't see much value in a tier 4: all other platforms that aren't
> tier 3 or above are tier 4.  We could link to a wiki page for where
> one might find links to support communities for non-tiered platforms,
> but I expect such a list would bitrot at a rate that makes it not
> worth including in the official tier list, whether by those
> communities fading away or the platform being promoted to tier 3.
>
>
> On Thu, Mar 10, 2022 at 5:36 PM Brett Cannon  wrote:
> > Tier 1
> > ==
> >
> > - `Test suite 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 working.
> > - Promotion of this tier requires consensus/SC approval.
>
> Should tier 1 require pre-merge CI?  We can currently do that, but
> promoting a platform that's not provided by GHA could require
> significant workflow changes.
>

That was meant to be implied by the "you can't break `main`" line, but I'm
happy to make that explicit.


>
> > - Must have a stable buildbot.
>
> I have concerns about the term "stable buildbot".  Until now, the
> "stable"/"unstable" tags on buildbots have been the closest thing
> we've had to a platform support policy and we've treated failures on a
> "stable" buildbot to be release blockers (for the most part).  With a
> proper platform support policy, "stable"/"unstable" should become a
> description of the reliability of the particular worker machine to
> provide an accurate representation of the state of the tests on the
> platform rather than whether the tests usually pass, but I'm worried
> about confusion from the changing meaning of those labels.
>

I'm somewhat using the term as a bridging mechanism. I'm assuming if this
change goes in that the buildbots representing these platforms will get
appropriate labels and that's really what's going to be representative of a
"stable buildbot". I'm also happy to change the wording to "reliable".
___
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/AFSLV6F3JNRZAHOYKSFYKZQFCIZK7YCA/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Brett Cannon 
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 understanding of that sentence is: PRs which target platforms
> > not listed in PEP 11 may not be checked in.
> >
> > IMO, it doesn't make sense to prohibit support code in the
> > code base, if there is community interest in this. By dropping
> > that line, we wouldn't have a problem and also don't
> > need to list platforms in a tier 4 section, since it's still
> > possible to add support in the main code base, without having
> > a core dev maintain it.
>
> I agree, the simplest solution here seems to be just to not include
> that line. We can still push back on PRs for unsupported platforms if
> we want, we just won't have a policy that *requires* us to do so.
>
> If it turns out that leaving it to core devs' judgement is a problem,
> we can agree a policy with some concrete examples to inform us.
>

It's already a guideline we hold, but I'm fine with weakening the language
to make more of a cautious warning to only merge paltform-specific code if
you have good reasons to.
___
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/5DRDOK6M2D3JADJKJT5BENOJ26GYGBUN/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Gregory P. Smith 
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 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 checked in.
>> >
>> > IMO, it doesn't make sense to prohibit support code in the
>> > code base, if there is community interest in this. By dropping
>> > that line, we wouldn't have a problem and also don't
>> > need to list platforms in a tier 4 section, since it's still
>> > possible to add support in the main code base, without having
>> > a core dev maintain it.
>>
>> I agree, the simplest solution here seems to be just to not include
>> that line. We can still push back on PRs for unsupported platforms if
>> we want, we just won't have a policy that *requires* us to do so.
>>
>> If it turns out that leaving it to core devs' judgement is a problem,
>> we can agree a policy with some concrete examples to inform us.
>>
>
> It's already a guideline we hold, but I'm fine with weakening the language
> to make more of a cautious warning to only merge paltform-specific code if
> you have good reasons to.
>

I wouldn't word it as a prohibition.  Just get rid of the line entirely.

I'd also get rid of Tier 3.  It isn't useful - that tier doesn't *block*
anything so we shouldn't be maintaining a documented list of things that
come and go at that level.  That's pure makework and conveys nothing that
the existence of a buildbot does not already do.

If you want a line to include about code supporting non tier1/2 platforms,
I'd word it as:

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

This simplifies the story and better reflects reality.  Things listed in a
tier are meaningful without 3 because they block releases rather than
needing to know that tier 3 is a no-op.

The buildbot concept of "stable" is arbitrary.  It is a configuration tag.
There is no strict authority to gatekeep and curate it.  If a release
manager or steering council said to remove the "stable" tag from a buildbot
they'd likely be listened to. Otherwise it's collectively up to whomever
maintains the bot configs and approves the config PRs.  Stability of a
machine setup for reliability purposes is unrelated to importance.

Ex: I don't tag my raspbian bot as "stable" because it lives at home where
I provide a SLO of nothing.  It has nothing to do with importance.  It is
clearly a more important platform than wasm today.

> .. [ubuntu-20_01]

Call this link ubuntu-20_04 to avoid confusion.  Ubuntu versions are always
YY.04 and YY.10 unless they miss their planned release window [rare].

-gps
___
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/YPQ7H5HD3X2EY522M75OM6CQQZNLWWOD/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Proposed tiered platform support

2022-03-11 Thread Victor Stinner 
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. Tier 2 should only target Fedora *Stable* (which
is the case ;-)).

> glibc XXX [fedora-stable]

Mentioning that Fedora uses glibc is nice, but I don't think that it's
worth it to mention the glibc version. Fedora is released every 6
months and the glibc version is updated at each Fedora release.

> x86_64-unknown-freebsd XXX
> https://buildbot.python.org/all/#/builders/172 XXX

You can put my name as Contact for the FreeBSD buildbot.

I don't *actively* support FreeBSD, but last years, I did "best
effort" support: add some FreeBSD features sometimes, adapt Python for
new FreeBSD changes, fix regressions specific to FreeBSD, investigate
unstable tests which only fail on FreeBSD, etc.

You can mention that FreeBSD now uses the "clang" C compiler, since
most Linux distributions (ex: RHEL) use GCC. It's a significant
difference.

Victor


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/GO4E74AJXKI4RKE7GAPHMOJQK5RCU3IF/
Code of Conduct: https://www.python.org/psf/codeofconduct/