[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Mon, Mar 14, 2022 at 11:18 PM Larry Hastings  wrote:

>
> On 3/14/22 20:31, Brett Cannon wrote:
>
>
>
> On Fri, Mar 11, 2022 at 5:17 PM Victor Stinner 
> wrote:
>
>> It would be great to have the list of supported platforms per Python
>> version!
>>
>
> I could see the table in PEP 11 being copied into the release PEPs.
>
>
> By "release PEPs", you mean the release schedule PEPs, like PEP 619
> "Python 3.10 Release Schedule"?
>
> https://peps.python.org/pep-0619/
>
>
Yep!


>
> Because, yeah, I think that would be the best place for it.  Though then
> maybe the name of the PEP should change, as the document is doing double
> duty.
>


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XLLPER26376AJNVT673W4HL5HWGESMT5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Larry Hastings]

On 3/14/22 20:31, Brett Cannon wrote:



On Fri, Mar 11, 2022 at 5:17 PM Victor Stinner  
wrote:


It would be great to have the list of supported platforms per
Python version!


I could see the table in PEP 11 being copied into the release PEPs.



By "release PEPs", you mean the release schedule PEPs, like PEP 619 
"Python 3.10 Release Schedule"?


   https://peps.python.org/pep-0619/

Because, yeah, I think that would be the best place for it. Though then 
maybe the name of the PEP should change, as the document is doing double 
duty.



//arry/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WBAV2X5JRHSMSO3374PZIVU7TU2WDP6E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Fri, Mar 11, 2022 at 5:17 PM Victor Stinner  wrote:

> It would be great to have the list of supported platforms per Python
> version!
>

I could see the table in PEP 11 being copied into the release PEPs.


>
> Maybe supporting new platforms and dropping support for a platform
> should be document in What's New in Python x.y. GCC does that for
> example. It also *deprecates* support for some platforms. Example:
> https://gcc.gnu.org/gcc-9/changes.html
>
> --
>
> It's always hard for me to know what is the minimum supported Windows
> version. PEP 11 refers to Windows support:
> https://peps.python.org/pep-0011/#microsoft-windows
>
> But I don't know how to get this info from the Microsoft
> documentation. I usually dig into Wikipedia articles to check which
> Windows version is still supported or not, but I'm confused between
> "mainstream support" and "extended support".
>

It's "free with purchase" and "pay us more and we will keep supporting
you". You can think of it as standard versus extended warranties.

https://docs.microsoft.com/en-us/lifecycle/policies/fixed


>
> For example, which Python version still support Windows 7? Wikipedia
> says that Windows 7 mainstream support ended in 2015, and extended
> support ended in 2020. But Python still has a Windows 7 SP1 buildbot
> for Python 3.8: https://buildbot.python.org/all/#/builders/60


Just because we have a buildbot does not mean we support it. All it means
is someone in the community cares enough about Windows 7 to want to know
when CPython no longer works.


>
>
> What is the minimum Windows supported by Python 3.10?
>

I believe it's Windows 8.

https://docs.microsoft.com/en-us/lifecycle/faq/windows
https://docs.microsoft.com/en-us/lifecycle/products/windows-81

-Brett


>
> Victor
>
> On Mon, Mar 7, 2022 at 8:06 PM Christian Heimes 
> wrote:
> >
> > On 07/03/2022 18.02, Petr Viktorin wrote:
> > >> Why the devguide? I view the list of platforms as important for public
> > >> consumption as for the core dev team to know what to (not) accept PRs
> > >> for.
> > >
> > > So, let's put it in the main docs?
> > > Yes, I guess the devguide is a weird place to check for this kind of
> > > info. But a Python enhancement proposal is even weirder.
> >
> >
> > +1 for our main docs (cpython/Doc/)
> >
> > Platform support is Python versions specific. Python 3.10 may support
> > different version than 3.11 or 3.12. It makes sense to keep the support
> > information with the code.
> >
> > Christian
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LJID7Y7RFSCRUYLJS3E56WBGJU2R44E4/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GCWULFTKFZNJFV7FWDMFBQVBMY5QBJJQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Jeremy Kloth]

On Fri, Mar 11, 2022 at 6:21 PM Victor Stinner  wrote:
> But I don't know how to get this info from the Microsoft
> documentation. I usually dig into Wikipedia articles to check which
> Windows version is still supported or not, but I'm confused between
> "mainstream support" and "extended support".

As PEP 11 states, it is the extended support time-frame that is of interest.

> For example, which Python version still support Windows 7? Wikipedia
> says that Windows 7 mainstream support ended in 2015, and extended
> support ended in 2020. But Python still has a Windows 7 SP1 buildbot
> for Python 3.8: https://buildbot.python.org/all/#/builders/60

Python 3.8.0 was release when Windows 7 SP1 was within the extended
support time-frame.  Therefore, Win7 is supported (and tested) until
3.8 reaches EOL.

> What is the minimum Windows supported by Python 3.10?

>From the link listed in PEP 11, Windows 8.1 does not leave extended
support until Jan 10, 2023.  So it seems that 3.10 and 3.11 will need
to support Windows 8.1.

-- 
Jeremy Kloth
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NFPSZD44DLFJS7CFGT2SVX3CSK7H5VRJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Victor Stinner]

It would be great to have the list of supported platforms per Python version!

Maybe supporting new platforms and dropping support for a platform
should be document in What's New in Python x.y. GCC does that for
example. It also *deprecates* support for some platforms. Example:
https://gcc.gnu.org/gcc-9/changes.html

--

It's always hard for me to know what is the minimum supported Windows
version. PEP 11 refers to Windows support:
https://peps.python.org/pep-0011/#microsoft-windows

But I don't know how to get this info from the Microsoft
documentation. I usually dig into Wikipedia articles to check which
Windows version is still supported or not, but I'm confused between
"mainstream support" and "extended support".

For example, which Python version still support Windows 7? Wikipedia
says that Windows 7 mainstream support ended in 2015, and extended
support ended in 2020. But Python still has a Windows 7 SP1 buildbot
for Python 3.8: https://buildbot.python.org/all/#/builders/60

What is the minimum Windows supported by Python 3.10?

Victor

On Mon, Mar 7, 2022 at 8:06 PM Christian Heimes  wrote:
>
> On 07/03/2022 18.02, Petr Viktorin wrote:
> >> Why the devguide? I view the list of platforms as important for public
> >> consumption as for the core dev team to know what to (not) accept PRs
> >> for.
> >
> > So, let's put it in the main docs?
> > Yes, I guess the devguide is a weird place to check for this kind of
> > info. But a Python enhancement proposal is even weirder.
>
>
> +1 for our main docs (cpython/Doc/)
>
> Platform support is Python versions specific. Python 3.10 may support
> different version than 3.11 or 3.12. It makes sense to keep the support
> information with the code.
>
> Christian
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/LJID7Y7RFSCRUYLJS3E56WBGJU2R44E4/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JJRNJWNRYC4R47YB64D6ZGO4325WG32R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Charalampos Stratakis]

On Fri, Mar 4, 2022 at 9:49 AM Christian Heimes 
wrote:

> Hi Brett,
>
> thanks for starting the discussion! Much appreciated.
>
> On 04/03/2022 00.30, Brett Cannon wrote:
> > Tier 1 is the stuff we run CI against: latest Windows, latest macOS,
> > Linux w/ the latest glibc (I don't know of a better way to define Linux
> > support as I don't know if a per-distro list is the right abstraction).
> > These are platforms we won't even let code be committed for if they
> > would break; they block releases if they don't work. These platforms we
> > all implicitly promise to support.
>  >
> > Tier 2 is the platforms we would revert a change within 24 hours if they
> > broke: latest FeeBSD, older Windows, older macOS, Linux w/ older
> > glibc.This is historically the "stable buildbot plus a core dev" group
> > of platforms. The change I would like to see is two core devs (in case
> > one is on vacation), and a policy as to how a platform ends up here
> > (e.g. SC must okay it based on consensus of everyone). The stable
> > buildbot would still be needed to know if a release is blocked as we
> > would hold a release up if they were red. The platform and the core devs
> > supporting these platforms would be listed in PEP 11.
>
> I would like to see an explicit statement about glibc compatibility.
> glibc's API and ABI is very stable. We have autoconf feature checks for
> newer glibc features, so I'm not overly concerned with breaking
> compatibility with glibc. Anyhow we should also ensure that we are
> backwards compatible with older glibc releases that are commonly used in
> the community.
>
> Therefore I propose that we target the oldest manylinux standard
> accepted by PyPI, for which the operating system has not reached its
> EOL. At the moment this is manylinux2014, aka CentOS 2024 with EOL June
> 2024. We could also state that we aim for compatibility with oldest
> Debian Stable and Ubuntu LTS with standard, free security updates. As of
> today Debian 10 Buster Ubuntu 18.04 Bionic are the oldest versions with
> regular updates.
>
>
> Apropos libc, what is our plan concerning musl libc (Alpine)? It's a
> popular distro for containers. CPython's test suite is failing on latest
> Alpine (https://bugs.python.org/issue46390). Some of the problems seem
> to be caused by issues or missing features in musl libc. I like to see
> the problems fixed before we claim basic support for Alpine.
>
>
> > I would expect PEP 11 to list the appropriate C symbol that's set for
> > that platform, e.g. __linux__.
>
> For POSIX-like OS I would rather follow the example of Rust and use
> platform target triplet. The triplet encodes machine (CPU arch), vendor,
> and operating system. The OS part can encode libc. For example
> x86_64-*-linux-gnu for "x84_64 arch", "any vendor", and "Linux with GNU
> libc (glibc)". Commands like ./config.guess or gcc -dumpmachine return
> the current triplet.
>
> The target triplet is used by autoconf's ./configure script a lot.
>
>
> > I don't know if we want to bother listing CPU architectures since we are
> > a pure C project which makes CPU architecture less of a thing, but I'm
> > personally open to the idea of CPU architectures being a part of the
> > platform definition.
>
> I strongly recommend that we include machine architecture, too. We have
> some code that uses machine specific instructions or features, e.g.
> unaligned memory access. We cannot debug problems on CPU archs unless we
> have access to the hardware.
>
>
Agreed, there have been various architecture specific bugs in the past and
the buildbots provide good coverage in that respect.


>
> > I don't think we should cover C compilers here as that's covered by PEP
> > 7. Otherwise PEP 7 should only list C versions/features and PEP 11 lists
> > compilers and their versions.
>
> We should say something about compilers. I wouldn't list compiler
> versions, though. Compiler features like C99 support should be sufficient.
>
> Do we target the platform's default compiler or are we targeting the
> latest compiler that is officially supported for the platform? CentOS 7
> comes with an old GCC, but has newer GCC versions in SCL (Developer
> Toolset 8). I'm asking because CentOS 7's default gcc does not support
> stdatomic.h. The official manylinux2014 OSCI container image ships GCC
> from devtoolset-8.
>
>
That's an interesting question and RHEL7 is a bit of a special case. If
mimalloc, for example, will be used in CPython, RHEL7/CentOS7 support is
out of the
question in regards to its default compiler. I've already changed the
config to some RHEL7 buildbots to use a later GCC version through the
Developer Toolset 8, so GCC 8.

The latest Python shipped through Red Hat Software Collection channels in
RHEL7 is Python 3.8, built using Developer Toolset 9 (GCC 9).

However, me and David Edelsohn are the only ones providing RHEL7 buildbots,
so coordinating a change to all the configs to use a later GCC version
should
be easy enough.

Another 

[Python-Dev] Re: Defining tiered platform support

[Petr Viktorin]

On 08. 03. 22 0:30, Brett Cannon wrote:



On Mon, Mar 7, 2022 at 11:05 AM Christian Heimes > wrote:


On 07/03/2022 18.02, Petr Viktorin wrote:
 >> Why the devguide? I view the list of platforms as important for
public
 >> consumption as for the core dev team to know what to (not)
accept PRs
 >> for.
 >
 > So, let's put it in the main docs?
 > Yes, I guess the devguide is a weird place to check for this kind of
 > info. But a Python enhancement proposal is even weirder.


+1 for our main docs (cpython/Doc/)

Platform support is Python versions specific. Python 3.10 may support
different version than 3.11 or 3.12. It makes sense to keep the support
information with the code.


Technically it's CPython version-specific. I also don't know where we 
would list this in the docs. Looking at https://docs.python.org/3/ 
 I wouldn't know where to look for such 
information.


Yeah, I kind of have the same issue with backcompat expectations 
(https://discuss.python.org/t/documenting-python-versioning-and-stability-expectations/11090). 
We might need a new section for this kind of CPython-specific docs.
Maybe repurpose the "Python Setup and Usage" section, which is 
CPython-specific already.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SBC4SNWPCFRMC4KYIPC2VUJU7REJQ6DU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Mon, Mar 7, 2022 at 11:05 AM Christian Heimes 
wrote:

> On 07/03/2022 18.02, Petr Viktorin wrote:
> >> Why the devguide? I view the list of platforms as important for public
> >> consumption as for the core dev team to know what to (not) accept PRs
> >> for.
> >
> > So, let's put it in the main docs?
> > Yes, I guess the devguide is a weird place to check for this kind of
> > info. But a Python enhancement proposal is even weirder.
>
>
> +1 for our main docs (cpython/Doc/)
>
> Platform support is Python versions specific. Python 3.10 may support
> different version than 3.11 or 3.12. It makes sense to keep the support
> information with the code.
>

Technically it's CPython version-specific. I also don't know where we would
list this in the docs. Looking at https://docs.python.org/3/ I wouldn't
know where to look for such information.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OYVN2XROV6DQ5IYBM5NT7EHSAJLDXFE5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Mon, Mar 7, 2022 at 11:01 AM Christian Heimes 
wrote:

> On 04/03/2022 21.41, Brett Cannon wrote:
> > Therefore I propose that we target the oldest manylinux standard
> > accepted by PyPI, for which the operating system has not reached its
> > EOL. At the moment this is manylinux2014, aka CentOS 2024 with EOL
> June
> > 2024. We could also state that we aim for compatibility with oldest
> > Debian Stable and Ubuntu LTS with standard, free security updates.
> > As of
> > today Debian 10 Buster Ubuntu 18.04 Bionic are the oldest versions
> with
> > regular updates.
> >
> >
> > So does that mean you want to list the Linux distros explicitly? Or you
> > want to explicitly list the glibc version?
>
> I want to explicitly mention glibc and Linux distro for manylinux binary
> wheels standards that are supported by PyPI. For the rest we should be a
> bit more hand-wavy. Maybe we can point to our list of stable buildbots?
>

How about we list Linux support as based on the libc implementation and
version and point as various stable buildbots that cover that libc?


>
> >
> > We should say something about compilers. I wouldn't list compiler
> > versions, though. Compiler features like C99 support should be
> > sufficient.
> >
> >
> > Then what more would you want than what's listed in PEP 7 already?
>
> Nothing in particular other than a link to the PEP, so people can
> discover the requirement more easily.
>


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OEN667JU2ATPU75XPOBZAAU4BS72IXCH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Christian Heimes]

On 07/03/2022 18.02, Petr Viktorin wrote:
Why the devguide? I view the list of platforms as important for public 
consumption as for the core dev team to know what to (not) accept PRs 
for.


So, let's put it in the main docs?
Yes, I guess the devguide is a weird place to check for this kind of 
info. But a Python enhancement proposal is even weirder.



+1 for our main docs (cpython/Doc/)

Platform support is Python versions specific. Python 3.10 may support 
different version than 3.11 or 3.12. It makes sense to keep the support 
information with the code.


Christian
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LJID7Y7RFSCRUYLJS3E56WBGJU2R44E4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Christian Heimes]

On 04/03/2022 21.41, Brett Cannon wrote:

Therefore I propose that we target the oldest manylinux standard
accepted by PyPI, for which the operating system has not reached its
EOL. At the moment this is manylinux2014, aka CentOS 2024 with EOL June
2024. We could also state that we aim for compatibility with oldest
Debian Stable and Ubuntu LTS with standard, free security updates.
As of
today Debian 10 Buster Ubuntu 18.04 Bionic are the oldest versions with
regular updates.


So does that mean you want to list the Linux distros explicitly? Or you 
want to explicitly list the glibc version?


I want to explicitly mention glibc and Linux distro for manylinux binary 
wheels standards that are supported by PyPI. For the rest we should be a 
bit more hand-wavy. Maybe we can point to our list of stable buildbots?




We should say something about compilers. I wouldn't list compiler
versions, though. Compiler features like C99 support should be
sufficient.


Then what more would you want than what's listed in PEP 7 already?


Nothing in particular other than a link to the PEP, so people can 
discover the requirement more easily.


Christian
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TM3NTO652FLS4XUX7QTMTP7GSX6DQRRH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Petr Viktorin]

On 04. 03. 22 21:48, Brett Cannon wrote:



On Fri, Mar 4, 2022 at 1:44 AM Petr Viktorin > wrote:


On 04. 03. 22 0:30, Brett Cannon wrote:
 > Do we officially support NetBSD? Do you know how to find out if
we do?
 > You might think to look at
 > https://www.python.org/dev/peps/pep-0011/#supporting-platforms

 > > , but
 > that just loosely defines the criteria and it still doesn't list the
 > actual platforms we support. (BTW I don't know if we do officially
 > support NetBSD, hence this email.)
 >
 > I think we should clarify this sort of thing and be a bit more
upfront
 > with the level of support we expect/provide for a platform. As
such, I
 > want to restructure PEP 11 to list the platforms we support, not
just
 > list the platforms we stopped supporting. To do this I want define 3
 > different tiers that outline what our support requirements and
promises
 > are for platforms.

While you're at it: consider moving the lists to the devguide, so the
PEP would only contain the general process & criteria.


Why the devguide? I view the list of platforms as important for public 
consumption as for the core dev team to know what to (not) accept PRs for.


So, let's put it in the main docs?
Yes, I guess the devguide is a weird place to check for this kind of 
info. But a Python enhancement proposal is even weirder.




 > Tier 1 is the stuff we run CI against: latest Windows, latest macOS,
 > Linux w/ the latest glibc (I don't know of a better way to define
Linux
 > support as I don't know if a per-distro list is the right
abstraction).
 > These are platforms we won't even let code be committed for if they
 > would break; they block releases if they don't work. These
platforms we
 > all implicitly promise to support.
 >
 > Tier 2 is the platforms we would revert a change within 24 hours
if they
 > broke: latest FeeBSD, older Windows, older macOS, Linux w/ older
 > glibc.This is historically the "stable buildbot plus a core dev"
group
 > of platforms. The change I would like to see is two core devs (in
case
 > one is on vacation), and a policy as to how a platform ends up here
 > (e.g. SC must okay it based on consensus of everyone). The stable
 > buildbot would still be needed to know if a release is blocked as we
 > would hold a release up if they were red. The platform and the
core devs
 > supporting these platforms would be listed in PEP 11.

Do we need two core devs to revert changes?


No, but consider you are trying to land something before b1 and a tier 2 
platform keeps failing. You have no idea why, but e.g. Victor is on 
vacation and is unavailable to help. I personally wouldn't want to wait 
until the next version of Python just because a platform we say we 
support had its expert take an inconvenient vacation.


Sure, requiring two core devs will help with that. But two seems about 
as arbitrary as one. People can have overlapping vacations, and some 
core devs are less responsive than Victor on vacation :)

Is this an existing, recurring issue we need to solve?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XTRF3IH4LN3Z6RC6KGS5IJCWMTL3GAYL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Fri, Mar 4, 2022 at 1:44 AM Petr Viktorin  wrote:

> On 04. 03. 22 0:30, Brett Cannon wrote:
> > Do we officially support NetBSD? Do you know how to find out if we do?
> > You might think to look at
> > https://www.python.org/dev/peps/pep-0011/#supporting-platforms
> >  , but
> > that just loosely defines the criteria and it still doesn't list the
> > actual platforms we support. (BTW I don't know if we do officially
> > support NetBSD, hence this email.)
> >
> > I think we should clarify this sort of thing and be a bit more upfront
> > with the level of support we expect/provide for a platform. As such, I
> > want to restructure PEP 11 to list the platforms we support, not just
> > list the platforms we stopped supporting. To do this I want define 3
> > different tiers that outline what our support requirements and promises
> > are for platforms.
>
> While you're at it: consider moving the lists to the devguide, so the
> PEP would only contain the general process & criteria.
>

Why the devguide? I view the list of platforms as important for public
consumption as for the core dev team to know what to (not) accept PRs for.


>
>
> > Tier 1 is the stuff we run CI against: latest Windows, latest macOS,
> > Linux w/ the latest glibc (I don't know of a better way to define Linux
> > support as I don't know if a per-distro list is the right abstraction).
> > These are platforms we won't even let code be committed for if they
> > would break; they block releases if they don't work. These platforms we
> > all implicitly promise to support.
> >
> > Tier 2 is the platforms we would revert a change within 24 hours if they
> > broke: latest FeeBSD, older Windows, older macOS, Linux w/ older
> > glibc.This is historically the "stable buildbot plus a core dev" group
> > of platforms. The change I would like to see is two core devs (in case
> > one is on vacation), and a policy as to how a platform ends up here
> > (e.g. SC must okay it based on consensus of everyone). The stable
> > buildbot would still be needed to know if a release is blocked as we
> > would hold a release up if they were red. The platform and the core devs
> > supporting these platforms would be listed in PEP 11.
>
> Do we need two core devs to revert changes?
>

No, but consider you are trying to land something before b1 and a tier 2
platform keeps failing. You have no idea why, but e.g. Victor is on
vacation and is unavailable to help. I personally wouldn't want to wait
until the next version of Python just because a platform we say we support
had its expert take an inconvenient vacation.


> What are the duties of someone listed for a platform, anyway?
>

I would expect they would be the reviewer of PRs for that platform. Also
domain expert to help out with questions as they arise if their platform
could potentially block a release or feature getting in.


>
> > Tier 3 are platforms we accept PRs for to keep working, but they won't
> > block a release. At least one core dev must be listed to be in charge of
> > PRs that affect the platform. A buildbot would be nice but not required.
> > I'm thinking either historical platforms we support or something like
> > Emscripten that's working towards being a tier 2 platform. I'm not sure
> > if we want to have explicit approval to be in this tier beyond the
> > outlined requirements, but obviously if a core dev isn't keeping up with
> > PRs then the platform will be dropped.
> >
> > All other platforms we do not directly support in the repository and it
> > is up to the community to keep functioning. We can obviously keep
> > accepting general patches to up compatibility, but platform-specific
> > patches for anything outside of these tiers wouldn't. No issue if
> > someone provides a buildbot for their own benefit, but these buildbots
> > would never hold anything up.
> >
> > When a Python version hits b1, then that platform is considered
> > supported for that version as long as the requirements outlined above
> > continue to be met. Once the Python version hits EOL then like anything,
> > support ends no matter what. We could capture the supported platforms
> > for a version in the release schedule PEP if people want >
> > I would expect appropriate labels being added to the builders listed at
> > https://buildbot.python.org/all/#/builders
> >  to signify which platforms
> > we block releases for (e.g. `tier-1,`, `tier-2`, or `release-blocker` as
> > a generic label).
> >
> > I would expect PEP 11 to list the appropriate C symbol that's set for
> > that platform, e.g. __linux__.
> >
> > I don't know if we want to bother listing CPU architectures since we are
> > a pure C project which makes CPU architecture less of a thing, but I'm
> > personally open to the idea of CPU architectures being a part of the
> > platform definition.
>
> IMO it would be good to be explicit wrt. testing and support. 

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Fri, Mar 4, 2022 at 1:32 AM Ronald Oussoren 
wrote:

>
>
> On 4 Mar 2022, at 00:30, Brett Cannon  wrote:
>
> Do we officially support NetBSD? Do you know how to find out if we do? You
> might think to look at
> https://www.python.org/dev/peps/pep-0011/#supporting-platforms , but that
> just loosely defines the criteria and it still doesn't list the actual
> platforms we support. (BTW I don't know if we do officially support NetBSD,
> hence this email.)
>
> I think we should clarify this sort of thing and be a bit more upfront
> with the level of support we expect/provide for a platform. As such, I want
> to restructure PEP 11 to list the platforms we support, not just list the
> platforms we stopped supporting. To do this I want define 3 different tiers
> that outline what our support requirements and promises are for platforms.
>
> Tier 1 is the stuff we run CI against: latest Windows, latest macOS, Linux
> w/ the latest glibc (I don't know of a better way to define Linux support
> as I don't know if a per-distro list is the right abstraction). These are
> platforms we won't even let code be committed for if they would break; they
> block releases if they don't work. These platforms we all implicitly
> promise to support.
>
> Tier 2 is the platforms we would revert a change within 24 hours if they
> broke: latest FeeBSD, older Windows, older macOS, Linux w/ older glibc.This
> is historically the "stable buildbot plus a core dev" group of platforms.
> The change I would like to see is two core devs (in case one is on
> vacation), and a policy as to how a platform ends up here (e.g. SC must
> okay it based on consensus of everyone). The stable buildbot would still be
> needed to know if a release is blocked as we would hold a release up if
> they were red. The platform and the core devs supporting these platforms
> would be listed in PEP 11.
>
>
> What’s the difference between Tier 1 and 2 other than that PRs are checked
> with tier 1 platforms before committing and with tier 2 afterwards?
>

Everyone on the core team supports tier 1, while for tier 2 there's only
those who specifically volunteer to support it.


>
> In particular, tier 1 contains windows server and not desktop (even though
> I expect that those are compatible as far as our use is concerned), and
> does not contain the macOS versions that we actually support in the
> installers on python.org (macOS 10.9 or later, both x86_64 and arm64).
> AFAIK support for macOS 10.9 in the python.org installers is now
> primarily, if not only, tested by Ned. That could, and probably should, be
> automated but that’s a significant amount of work.
>

So macOS 10.9 would be tier 3. There's nothing wrong with that, just we
obviously don't know when it fails now anyway, so it technically only holds
up a release so much as Ned as RM for macOS builds can choose to.


>
>
> […]
>
>
>
> I don't know if we want to bother listing CPU architectures since we are a
> pure C project which makes CPU architecture less of a thing, but I'm
> personally open to the idea of CPU architectures being a part of the
> platform definition.
>
>
> CTypes is hardware specific, although through libiff. There’s also
> intermittent discussions about support for ancient hardware platforms.
> Would we block a release when (for example) support for Linux on sparc32 is
> broken?
>

If it's tier 2 or higher, yes.

-Brett


>
>
> Ronald
>
> —
>
> Twitter / micro.blog: @ronaldoussoren
> Blog: https://blog.ronaldoussoren.net/
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PQQSPHK6HSOGYCFJ6NIVMJJISSWNYU3Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Brett Cannon]

On Fri, Mar 4, 2022 at 12:48 AM Christian Heimes 
wrote:

> Hi Brett,
>
> thanks for starting the discussion! Much appreciated.
>
> On 04/03/2022 00.30, Brett Cannon wrote:
> > Tier 1 is the stuff we run CI against: latest Windows, latest macOS,
> > Linux w/ the latest glibc (I don't know of a better way to define Linux
> > support as I don't know if a per-distro list is the right abstraction).
> > These are platforms we won't even let code be committed for if they
> > would break; they block releases if they don't work. These platforms we
> > all implicitly promise to support.
>  >
> > Tier 2 is the platforms we would revert a change within 24 hours if they
> > broke: latest FeeBSD, older Windows, older macOS, Linux w/ older
> > glibc.This is historically the "stable buildbot plus a core dev" group
> > of platforms. The change I would like to see is two core devs (in case
> > one is on vacation), and a policy as to how a platform ends up here
> > (e.g. SC must okay it based on consensus of everyone). The stable
> > buildbot would still be needed to know if a release is blocked as we
> > would hold a release up if they were red. The platform and the core devs
> > supporting these platforms would be listed in PEP 11.
>
> I would like to see an explicit statement about glibc compatibility.
> glibc's API and ABI is very stable. We have autoconf feature checks for
> newer glibc features, so I'm not overly concerned with breaking
> compatibility with glibc. Anyhow we should also ensure that we are
> backwards compatible with older glibc releases that are commonly used in
> the community.
>
> Therefore I propose that we target the oldest manylinux standard
> accepted by PyPI, for which the operating system has not reached its
> EOL. At the moment this is manylinux2014, aka CentOS 2024 with EOL June
> 2024. We could also state that we aim for compatibility with oldest
> Debian Stable and Ubuntu LTS with standard, free security updates. As of
> today Debian 10 Buster Ubuntu 18.04 Bionic are the oldest versions with
> regular updates.
>

So does that mean you want to list the Linux distros explicitly? Or you
want to explicitly list the glibc version?


>
>
> Apropos libc, what is our plan concerning musl libc (Alpine)? It's a
> popular distro for containers. CPython's test suite is failing on latest
> Alpine (https://bugs.python.org/issue46390). Some of the problems seem
> to be caused by issues or missing features in musl libc. I like to see
> the problems fixed before we claim basic support for Alpine.
>
>
> > I would expect PEP 11 to list the appropriate C symbol that's set for
> > that platform, e.g. __linux__.
>
> For POSIX-like OS I would rather follow the example of Rust and use
> platform target triplet. The triplet encodes machine (CPU arch), vendor,
> and operating system. The OS part can encode libc. For example
> x86_64-*-linux-gnu for "x84_64 arch", "any vendor", and "Linux with GNU
> libc (glibc)". Commands like ./config.guess or gcc -dumpmachine return
> the current triplet.
>
> The target triplet is used by autoconf's ./configure script a lot.
>

That's fine by me if others agree.


>
>
> > I don't know if we want to bother listing CPU architectures since we are
> > a pure C project which makes CPU architecture less of a thing, but I'm
> > personally open to the idea of CPU architectures being a part of the
> > platform definition.
>
> I strongly recommend that we include machine architecture, too. We have
> some code that uses machine specific instructions or features, e.g.
> unaligned memory access. We cannot debug problems on CPU archs unless we
> have access to the hardware.
>

Based on other replies it sounds like that's what people want.


>
>
> > I don't think we should cover C compilers here as that's covered by PEP
> > 7. Otherwise PEP 7 should only list C versions/features and PEP 11 lists
> > compilers and their versions.
>
> We should say something about compilers. I wouldn't list compiler
> versions, though. Compiler features like C99 support should be sufficient.
>

Then what more would you want than what's listed in PEP 7 already?


>
> Do we target the platform's default compiler or are we targeting the
> latest compiler that is officially supported for the platform? CentOS 7
> comes with an old GCC, but has newer GCC versions in SCL (Developer
> Toolset 8). I'm asking because CentOS 7's default gcc does not support
> stdatomic.h. The official manylinux2014 OSCI container image ships GCC
> from devtoolset-8.
>

I think that depends on the person supporting the platform.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/V2SLVKWYW3PSKPD3HI6QFJDSXD526TFR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Simon Cross]

+10 on making the tier platform support explicit.

I would vote not to require involving the SC in the tier changes
unless there is a strong reason to do so (e.g. there is controversy,
or e.g. Tier 1 implies a commitment of PSF infrastructure). The SC has
a lot of decisions to make as it is & hopefully Tier 2 and 3 are
really about checking a checklist (are there enough core devs
committed, are the buildbots in place, etc) that is already defined in
the PEP.

Replies to some other replies in the thread:

I like Christian's idea of explicitly supporting platforms such as
manylinux2014, Debian stable, Ubuntu stable where C extensions are
commonly built. It would help make those de facto standards more
official. Or some of the platforms supported by cibuildwheel (to
include non-Linux platforms).

I would prefer having the list in a PEP rather than the devguide. The
devguide is important, but it doesn't feel like a canonical reference
place for this sort of information.

Regards,
Simon
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/W5DJ6QAALCJQPC2AYEW36F5VS63KV5MJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Petr Viktorin]

On 04. 03. 22 0:30, Brett Cannon wrote:
Do we officially support NetBSD? Do you know how to find out if we do? 
You might think to look at 
https://www.python.org/dev/peps/pep-0011/#supporting-platforms 
 , but 
that just loosely defines the criteria and it still doesn't list the 
actual platforms we support. (BTW I don't know if we do officially 
support NetBSD, hence this email.)


I think we should clarify this sort of thing and be a bit more upfront 
with the level of support we expect/provide for a platform. As such, I 
want to restructure PEP 11 to list the platforms we support, not just 
list the platforms we stopped supporting. To do this I want define 3 
different tiers that outline what our support requirements and promises 
are for platforms.


While you're at it: consider moving the lists to the devguide, so the 
PEP would only contain the general process & criteria.



Tier 1 is the stuff we run CI against: latest Windows, latest macOS, 
Linux w/ the latest glibc (I don't know of a better way to define Linux 
support as I don't know if a per-distro list is the right abstraction). 
These are platforms we won't even let code be committed for if they 
would break; they block releases if they don't work. These platforms we 
all implicitly promise to support.


Tier 2 is the platforms we would revert a change within 24 hours if they 
broke: latest FeeBSD, older Windows, older macOS, Linux w/ older 
glibc.This is historically the "stable buildbot plus a core dev" group 
of platforms. The change I would like to see is two core devs (in case 
one is on vacation), and a policy as to how a platform ends up here 
(e.g. SC must okay it based on consensus of everyone). The stable 
buildbot would still be needed to know if a release is blocked as we 
would hold a release up if they were red. The platform and the core devs 
supporting these platforms would be listed in PEP 11.


Do we need two core devs to revert changes?
What are the duties of someone listed for a platform, anyway?

Tier 3 are platforms we accept PRs for to keep working, but they won't 
block a release. At least one core dev must be listed to be in charge of 
PRs that affect the platform. A buildbot would be nice but not required. 
I'm thinking either historical platforms we support or something like 
Emscripten that's working towards being a tier 2 platform. I'm not sure 
if we want to have explicit approval to be in this tier beyond the 
outlined requirements, but obviously if a core dev isn't keeping up with 
PRs then the platform will be dropped.


All other platforms we do not directly support in the repository and it 
is up to the community to keep functioning. We can obviously keep 
accepting general patches to up compatibility, but platform-specific 
patches for anything outside of these tiers wouldn't. No issue if 
someone provides a buildbot for their own benefit, but these buildbots 
would never hold anything up.


When a Python version hits b1, then that platform is considered 
supported for that version as long as the requirements outlined above 
continue to be met. Once the Python version hits EOL then like anything, 
support ends no matter what. We could capture the supported platforms 
for a version in the release schedule PEP if people want >
I would expect appropriate labels being added to the builders listed at 
https://buildbot.python.org/all/#/builders 
 to signify which platforms 
we block releases for (e.g. `tier-1,`, `tier-2`, or `release-blocker` as 
a generic label).


I would expect PEP 11 to list the appropriate C symbol that's set for 
that platform, e.g. __linux__.


I don't know if we want to bother listing CPU architectures since we are 
a pure C project which makes CPU architecture less of a thing, but I'm 
personally open to the idea of CPU architectures being a part of the 
platform definition.


IMO it would be good to be explicit wrt. testing and support. There's a 
lot of arch/compiler assumptions still hidden in the codebase.


I don't think we should cover C compilers here as that's covered by PEP 
7. Otherwise PEP 7 should only list C versions/features and PEP 11 lists 
compilers and their versions.


I think it would be good to move that here. It's a “platform support” 
matter, not “code style”.


FYI the tier support idea and the rough definitions above come from 
Rust: https://doc.rust-lang.org/nightly/rustc/platform-support.html 
 .


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Ronald Oussoren via Python-Dev]

> On 4 Mar 2022, at 00:30, Brett Cannon  wrote:
> 
> Do we officially support NetBSD? Do you know how to find out if we do? You 
> might think to look at 
> https://www.python.org/dev/peps/pep-0011/#supporting-platforms 
>  , but that 
> just loosely defines the criteria and it still doesn't list the actual 
> platforms we support. (BTW I don't know if we do officially support NetBSD, 
> hence this email.)
> 
> I think we should clarify this sort of thing and be a bit more upfront with 
> the level of support we expect/provide for a platform. As such, I want to 
> restructure PEP 11 to list the platforms we support, not just list the 
> platforms we stopped supporting. To do this I want define 3 different tiers 
> that outline what our support requirements and promises are for platforms.
> 
> Tier 1 is the stuff we run CI against: latest Windows, latest macOS, Linux w/ 
> the latest glibc (I don't know of a better way to define Linux support as I 
> don't know if a per-distro list is the right abstraction). These are 
> platforms we won't even let code be committed for if they would break; they 
> block releases if they don't work. These platforms we all implicitly promise 
> to support.
> 
> Tier 2 is the platforms we would revert a change within 24 hours if they 
> broke: latest FeeBSD, older Windows, older macOS, Linux w/ older glibc.This 
> is historically the "stable buildbot plus a core dev" group of platforms. The 
> change I would like to see is two core devs (in case one is on vacation), and 
> a policy as to how a platform ends up here (e.g. SC must okay it based on 
> consensus of everyone). The stable buildbot would still be needed to know if 
> a release is blocked as we would hold a release up if they were red. The 
> platform and the core devs supporting these platforms would be listed in PEP 
> 11.

What’s the difference between Tier 1 and 2 other than that PRs are checked with 
tier 1 platforms before committing and with tier 2 afterwards?   

In particular, tier 1 contains windows server and not desktop (even though I 
expect that those are compatible as far as our use is concerned), and does not 
contain the macOS versions that we actually support in the installers on 
python.org  (macOS 10.9 or later, both x86_64 and arm64). 
AFAIK support for macOS 10.9 in the python.org  installers 
is now primarily, if not only, tested by Ned. That could, and probably should, 
be automated but that’s a significant amount of work. 

[…]

> 
> 
> I don't know if we want to bother listing CPU architectures since we are a 
> pure C project which makes CPU architecture less of a thing, but I'm 
> personally open to the idea of CPU architectures being a part of the platform 
> definition.

CTypes is hardware specific, although through libiff. There’s also intermittent 
discussions about support for ancient hardware platforms. Would we block a 
release when (for example) support for Linux on sparc32 is broken?  

Ronald

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VDCMUXNSAMJGSHD6A235WBDHI7YETLVQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Defining tiered platform support

[Christian Heimes]

Hi Brett,

thanks for starting the discussion! Much appreciated.

On 04/03/2022 00.30, Brett Cannon wrote:
Tier 1 is the stuff we run CI against: latest Windows, latest macOS, 
Linux w/ the latest glibc (I don't know of a better way to define Linux 
support as I don't know if a per-distro list is the right abstraction). 
These are platforms we won't even let code be committed for if they 
would break; they block releases if they don't work. These platforms we 
all implicitly promise to support.

>
Tier 2 is the platforms we would revert a change within 24 hours if they 
broke: latest FeeBSD, older Windows, older macOS, Linux w/ older 
glibc.This is historically the "stable buildbot plus a core dev" group 
of platforms. The change I would like to see is two core devs (in case 
one is on vacation), and a policy as to how a platform ends up here 
(e.g. SC must okay it based on consensus of everyone). The stable 
buildbot would still be needed to know if a release is blocked as we 
would hold a release up if they were red. The platform and the core devs 
supporting these platforms would be listed in PEP 11.


I would like to see an explicit statement about glibc compatibility. 
glibc's API and ABI is very stable. We have autoconf feature checks for 
newer glibc features, so I'm not overly concerned with breaking 
compatibility with glibc. Anyhow we should also ensure that we are 
backwards compatible with older glibc releases that are commonly used in 
the community.


Therefore I propose that we target the oldest manylinux standard 
accepted by PyPI, for which the operating system has not reached its 
EOL. At the moment this is manylinux2014, aka CentOS 2024 with EOL June 
2024. We could also state that we aim for compatibility with oldest 
Debian Stable and Ubuntu LTS with standard, free security updates. As of 
today Debian 10 Buster Ubuntu 18.04 Bionic are the oldest versions with 
regular updates.



Apropos libc, what is our plan concerning musl libc (Alpine)? It's a 
popular distro for containers. CPython's test suite is failing on latest 
Alpine (https://bugs.python.org/issue46390). Some of the problems seem 
to be caused by issues or missing features in musl libc. I like to see 
the problems fixed before we claim basic support for Alpine.



I would expect PEP 11 to list the appropriate C symbol that's set for 
that platform, e.g. __linux__.


For POSIX-like OS I would rather follow the example of Rust and use 
platform target triplet. The triplet encodes machine (CPU arch), vendor, 
and operating system. The OS part can encode libc. For example 
x86_64-*-linux-gnu for "x84_64 arch", "any vendor", and "Linux with GNU 
libc (glibc)". Commands like ./config.guess or gcc -dumpmachine return 
the current triplet.


The target triplet is used by autoconf's ./configure script a lot.


I don't know if we want to bother listing CPU architectures since we are 
a pure C project which makes CPU architecture less of a thing, but I'm 
personally open to the idea of CPU architectures being a part of the 
platform definition.


I strongly recommend that we include machine architecture, too. We have 
some code that uses machine specific instructions or features, e.g. 
unaligned memory access. We cannot debug problems on CPU archs unless we 
have access to the hardware.



I don't think we should cover C compilers here as that's covered by PEP 
7. Otherwise PEP 7 should only list C versions/features and PEP 11 lists 
compilers and their versions.


We should say something about compilers. I wouldn't list compiler 
versions, though. Compiler features like C99 support should be sufficient.


Do we target the platform's default compiler or are we targeting the 
latest compiler that is officially supported for the platform? CentOS 7 
comes with an old GCC, but has newer GCC versions in SCL (Developer 
Toolset 8). I'm asking because CentOS 7's default gcc does not support 
stdatomic.h. The official manylinux2014 OSCI container image ships GCC 
from devtoolset-8.


Christian
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5LDLSPQVYLVKNEJADOFBQQ3TKBCFEDEV/
Code of Conduct: http://python.org/psf/codeofconduct/