Proposed tiered platform support
I brought this up on python-dev at
https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP3...
, 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
mainbranch 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/htm...
Tier 3
- Must have a stable buildbot.
- Code may be checked into
mainfor 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 ========================= ========================== ============================================== ======== wasm32-unknown-emscripten XXX XXX Brett Cannon, Christian Heimes wasm32-unknown-wasi XXX XXX Brett Cannon, Christian Heimes ========================= ========================== ============================================== ========
All other platforms
- Only code which either supports a higher-tier platform or is a general improvement may be checked in.
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/python-dev@python.org/thread/ZPBSHENP3... , 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
XXXplaceholders 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
mainbranch 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/htm...
Tier 3
- Must have a stable buildbot.
- Code may be checked into
mainfor 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 ========================= ========================== ============================================== ======== wasm32-unknown-emscripten XXX XXX Brett Cannon, Christian Heimes wasm32-unknown-wasi XXX XXX Brett Cannon, Christian Heimes ========================= ========================== ============================================== ========
All other platforms
- Only code which either supports a higher-tier platform or is a general improvement may be checked in.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/K... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- 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/
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
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/
On Fri, Mar 11, 2022 at 7:45 AM Marc-Andre Lemburg <mal@egenix.com> 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 <brett@python.org> 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
mainbranch 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.
On 11.03.2022 17:42, Zachary Ware wrote:
On Fri, Mar 11, 2022 at 7:45 AM Marc-Andre Lemburg <mal@egenix.com> 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/
On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg <mal@egenix.com> 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
On Fri, Mar 11, 2022 at 9:16 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg <mal@egenix.com> 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.
On Fri, Mar 11, 2022 at 10:45 AM Brett Cannon <brett@python.org> wrote:
On Fri, Mar 11, 2022 at 9:16 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg <mal@egenix.com> 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
On Fri, Mar 11, 2022 at 12:37 PM Gregory P. Smith <greg@krypto.org> wrote:
On Fri, Mar 11, 2022 at 10:45 AM Brett Cannon <brett@python.org> wrote:
On Fri, Mar 11, 2022 at 9:16 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Fri, 11 Mar 2022 at 17:09, Marc-Andre Lemburg <mal@egenix.com> 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."
I'm fine with that. It still lets those of us working on WebAssembly to upstream stuff but we can't claim full support until we get a Buildbot which seems fair.
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.
I think it's more about making sure if we are going to let a Buildbot run block a release we want to make sure that it's reliable enough to use for that purpose. I think using the term "stable" is unfortunately overloaded, so I won't plan to use it.
-Brett
.. [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
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
On Fri, Mar 11, 2022 at 8:43 AM Zachary Ware <zach@python.org> wrote:
On Fri, Mar 11, 2022 at 7:45 AM Marc-Andre Lemburg <mal@egenix.com> 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 <brett@python.org> 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
mainbranch 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".
On Fri, Mar 11, 2022 at 1:18 AM Marc-Andre Lemburg <mal@egenix.com> 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
, 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
XXXplaceholders forhelp me fill in to see how this will look overall.
For any platform(s) you support, please reply with any relevant details
https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP3... people to 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
mainbranch 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/htm...
Tier 3
- Must have a stable buildbot.
- Code may be checked into
mainfor 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========================= ========================== ============================================== ======== wasm32-unknown-emscripten XXX XXX
Brett Cannon, Christian Heimeswasm32-unknown-wasi XXX XXX
Brett Cannon, Christian Heimes========================= ========================== ============================================== ========
All other platforms
- Only code which either supports a higher-tier platform or is a general improvement may be checked in.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/K...
Code of Conduct: https://www.python.org/psf/codeofconduct/
-- 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/
On 11.03.2022 19:26, Brett Cannon wrote:
On Fri, Mar 11, 2022 at 1:18 AM Marc-Andre Lemburg <mal@egenix.com <mailto:mal@egenix.com>> 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 imagesI 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?
I've not built on AIX in a longer while, but the AIX Toolbox lists Python 3.9 as a package, so at least that version builds on AIX:
https://www.ibm.com/support/pages/aix-toolbox-open-source-software-downloads... http://www.aixtools.net/index.php/python3 https://www.ibm.com/support/pages/tips-installing-python-or-other-aix-toolbo...
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 🤷.
If people start to rely on PEP 11 for determining whether Python has support for a certain platform or not, I believe it's important to list such 3rd party efforts in the PEP as well. Otherwise, we'd be cutting off those efforts from being taken seriously and put off people who want to invest time into bringing Python to their platform.
My preference would be to not have PEP 11 limit support we add to the core for platforms which the core team does not support directly. It's fine to list platforms we actively support, but not to outrule adding support for platforms which are community supported.
Easiest would be to drop the line at the end of the proposed change.
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.
Fair enough.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 12 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/
On Sat, Mar 12, 2022 at 5:29 AM Marc-Andre Lemburg <mal@egenix.com> wrote:
On 11.03.2022 19:26, Brett Cannon wrote:
On Fri, Mar 11, 2022 at 1:18 AM Marc-Andre Lemburg <mal@egenix.com> 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?
I've not built on AIX in a longer while, but the AIX Toolbox lists Python 3.9 as a package, so at least that version builds on AIX:
https://www.ibm.com/support/pages/aix-toolbox-open-source-software-downloads... http://www.aixtools.net/index.php/python3
https://www.ibm.com/support/pages/tips-installing-python-or-other-aix-toolbo...
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 🤷.
If people start to rely on PEP 11 for determining whether Python has support for a certain platform or not, I believe it's important to list such 3rd party efforts in the PEP as well. Otherwise, we'd be cutting off those efforts from being taken seriously and put off people who want to invest time into bringing Python to their platform.
My preference would be to not have PEP 11 limit support we add to the core for platforms which the core team does not support directly. It's fine to list platforms we actively support, but not to outrule adding support for platforms which are community supported.
Easiest would be to drop the line at the end of the proposed change.
Greg proposed something like "Code changes to support platforms beyond tier1 or tier2 may be rejected, broken, or removed from the CPython codebase without notice if they cause a maintenance burden for tier1&2 or obstruct general improvements." and drop the concept of tier 3. Does that work for you?
-Brett
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.
Fair enough.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 12 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/
On 14.03.2022 19:34, Brett Cannon wrote:
Greg proposed something like "Code changes to support platforms beyond tier1 or tier2 may be rejected, broken, or removed from the CPython codebase without notice if they cause a maintenance burden for tier1&2 or obstruct general improvements." and drop the concept of tier 3. Does that work for you?
Almost :-) I don't understand the "without notice". I guess Greg meant "without deprecation process". Removal of support code should be discussed on a ticket and then listed in PEP 11 and mentioned in the NEWS file, as usual.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 14 2022)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/
On Mon, Mar 14, 2022 at 11:43 AM Marc-Andre Lemburg <mal@egenix.com> wrote:
On 14.03.2022 19:34, Brett Cannon wrote:
Greg proposed something like "Code changes to support platforms beyond tier1 or tier2 may be rejected, broken, or removed from the CPython codebase without notice if they cause a maintenance burden for tier1&2 or obstruct general improvements." and drop the concept of tier 3. Does that work for you?
Almost :-) I don't understand the "without notice". I guess Greg meant "without deprecation process". Removal of support code should be discussed on a ticket and then listed in PEP 11 and mentioned in the NEWS file, as usual.
I guess I was trying to convey that we may not even have a way to know that we're breaking something on a non-tier1/2 platform anyways so "without notice" was just me trying to set people's expectations. We don't go out of our way to _try_ and break things most of the time. "without a deprecation process" is also reasonable wording. Feel free to adopt those words.
Ideally we try to have discussion somewhere relevant when we _know_ we'd intentionally be removing support for something (for example of why: See the debacle that happened when dropping Solaris support was proposed).
-gps
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 14 2022)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/S... Code of Conduct: https://www.python.org/psf/codeofconduct/
After considering everyone's feedback, here are my proposed explanations for the tiers.
Tier 1
CI failures < https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>__ block releases.- Changes which would break the
mainbranch are not allowed to be merged; any breakage may be reverted immediately. - All core developers are responsible to keep these platforms,
and thus
main, working. - Promotion to this tier requires team consensus/SC approval.
Tier 2
- Must have a reliable buildbot.
- At least **two** core developers are signed up to support the platform.
- Changes which break any of these platforms are to be fixed or reverted within 24 hours.
- Failures on these platforms block a release.
- Promotion to this tier requires consensus/SC approval.
All other platforms
Support for a platform may be partial within the code base, such as from active development around platform support or accidentally. Code changes to platforms not listed in the above tiers may rejected or removed from the code base without a deprecation process if they cause a maintenance burden or obstruct general improvements.
Platforms not listed here may be supported by the wider Python community in some way. If your desired platform is not listed above, please perform a search online to see if someone is already providing support in some form.
I have a draft PR up at https://github.com/python/peps/pull/2442 which can be previewed at https://pep-previews--2442.org.readthedocs.build/pep-0011/ (makes reading the table much easier). I made the platforms list the platform triple, libc, and compiler **without** version details.
Once I have buy-in for the above I will explicitly ask folks to send review comments to that PR to add themselves to the platforms they are willing to support, and then drop any which lack two core developers (warnings to the Fedora/RH folks: most of those platforms are listed are using Fedora buildbots, so it might be up to you 😉). I did drop powerpc-linux-gnu from the list as that buildbot has not successfully built in quite some time (powerpcle seems fine).
On Mon, Mar 14, 2022 at 5:35 PM Gregory P. Smith <greg@krypto.org> wrote:
On Mon, Mar 14, 2022 at 11:43 AM Marc-Andre Lemburg <mal@egenix.com> wrote:
On 14.03.2022 19:34, Brett Cannon wrote:
Greg proposed something like "Code changes to support platforms beyond tier1 or tier2 may be rejected, broken, or removed from the CPython codebase without notice if they cause a maintenance burden for tier1&2 or obstruct general improvements." and drop the concept of tier 3. Does that work for you?
Almost :-) I don't understand the "without notice". I guess Greg meant "without deprecation process". Removal of support code should be discussed on a ticket and then listed in PEP 11 and mentioned in the NEWS file, as usual.
I guess I was trying to convey that we may not even have a way to know that we're breaking something on a non-tier1/2 platform anyways so "without notice" was just me trying to set people's expectations. We don't go out of our way to _try_ and break things most of the time. "without a deprecation process" is also reasonable wording. Feel free to adopt those words.
Ideally we try to have discussion somewhere relevant when we _know_ we'd intentionally be removing support for something (for example of why: See the debacle that happened when dropping Solaris support was proposed).
-gps
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 14 2022)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/S... Code of Conduct: https://www.python.org/psf/codeofconduct/
Based on the positive feedback that I've gotten on this and the only other suggestion was maybe bringing back tier 3 to represent, "being actively worked on" support (which i think we can add later if we feel it's worth it), I'm ready to ask folks to please start sending review suggestions on https://github.com/python/peps/pull/2442 to add yourself as supporting a platform (see https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/re... if you don't know what I mean by "review suggestion").
I believe at least Victor is currently out at the moment, so I'm not planning to rush this out and start removing platforms that lack two people and merging this PR, but I also don't want to put it off either. As a reminder, the platforms looking for declared support as a tier 2 platform are:
- arch64-apple-darwin clang
- aarch64-linux-gnu glibc, gcc
- aarch64-linux-gnu glibc, clang
- aarch64-windows-msvc
- powerpcle-linux-gnu glibc, gcc
- powerpcle-linux-gnu glibc, clang
- s390x-linux-gnu glibc, gcc
- s390x-linux-gnu glibc, clang
- x86_64-linux-gnu glibc, clang
- x86_64-unknown-freebsd BSD libc, cc
Tier 1 is taken care of:
- i686-windows-msvc
- x86_64-windows-msvc
- x86_64-apple-darwin BSD libc, clang
- x86_64-linux-gnu glibc, gcc
On Thu, Mar 17, 2022 at 5:56 PM Brett Cannon <brett@python.org> wrote:
After considering everyone's feedback, here are my proposed explanations for the tiers.
Tier 1
CI failures < https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>__ block releases.- Changes which would break the
mainbranch are not allowed to be merged; any breakage may be reverted immediately.- All core developers are responsible to keep these platforms, and thus
main, working.- Promotion to this tier requires team consensus/SC approval.
Tier 2
- Must have a reliable buildbot.
- At least **two** core developers are signed up to support the platform.
- Changes which break any of these platforms are to be fixed or reverted within 24 hours.
- Failures on these platforms block a release.
- Promotion to this tier requires consensus/SC approval.
All other platforms
Support for a platform may be partial within the code base, such as from active development around platform support or accidentally. Code changes to platforms not listed in the above tiers may rejected or removed from the code base without a deprecation process if they cause a maintenance burden or obstruct general improvements.
Platforms not listed here may be supported by the wider Python community in some way. If your desired platform is not listed above, please perform a search online to see if someone is already providing support in some form.
I have a draft PR up at https://github.com/python/peps/pull/2442 which can be previewed at https://pep-previews--2442.org.readthedocs.build/pep-0011/ (makes reading the table much easier). I made the platforms list the platform triple, libc, and compiler **without** version details.
Once I have buy-in for the above I will explicitly ask folks to send review comments to that PR to add themselves to the platforms they are willing to support, and then drop any which lack two core developers (warnings to the Fedora/RH folks: most of those platforms are listed are using Fedora buildbots, so it might be up to you 😉). I did drop powerpc-linux-gnu from the list as that buildbot has not successfully built in quite some time (powerpcle seems fine).
On Mon, Mar 14, 2022 at 5:35 PM Gregory P. Smith <greg@krypto.org> wrote:
On Mon, Mar 14, 2022 at 11:43 AM Marc-Andre Lemburg <mal@egenix.com> wrote:
On 14.03.2022 19:34, Brett Cannon wrote:
Greg proposed something like "Code changes to support platforms beyond tier1 or tier2 may be rejected, broken, or removed from the CPython codebase without notice if they cause a maintenance burden for tier1&2 or obstruct general improvements." and drop the concept of tier 3. Does that work for you?
Almost :-) I don't understand the "without notice". I guess Greg meant "without deprecation process". Removal of support code should be discussed on a ticket and then listed in PEP 11 and mentioned in the NEWS file, as usual.
I guess I was trying to convey that we may not even have a way to know that we're breaking something on a non-tier1/2 platform anyways so "without notice" was just me trying to set people's expectations. We don't go out of our way to _try_ and break things most of the time. "without a deprecation process" is also reasonable wording. Feel free to adopt those words.
Ideally we try to have discussion somewhere relevant when we _know_ we'd intentionally be removing support for something (for example of why: See the debacle that happened when dropping Solaris support was proposed).
-gps
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 14 2022)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/S... Code of Conduct: https://www.python.org/psf/codeofconduct/
You wrote that you want at least 2 core devs responsible for each tier 1 platform. I didn't understand if this requirement is also for Tier 2.
Who are these core devs? Is there a list?
Victor
On 25. 03. 22 11:43, Victor Stinner wrote:
You wrote that you want at least 2 core devs responsible for each tier 1 platform. I didn't understand if this requirement is also for Tier 2.
Who are these core devs? Is there a list?
The list will be in the PEP. Add yourself at https://github.com/python/peps/pull/2442 as a review suggestion. That PR also has the current text of the proposal.
I dislike the Tier 1 rule "All core developers are responsible to keep
these platforms, and thus main, working."
In my experience, "Everyone is reponsible" means in practice "nobody is responsible". IMO you must also put two names in front of each platform. Otherwise, nobody will fix them when it will be broken, and the best that we will be able to do is to just revert the change breaking the CI which prevents adding new features just because nobody wants to fix the CI.
Sometimes, a broken CI is unrelated to a Python change. Things break, *all the time*, for many various reasons including vacuum cleaners (*)!
(*) https://mail.python.org/archives/list/python-buildbots@python.org/message/27...
Victor
On Fri, Mar 25, 2022 at 4:23 AM Victor Stinner <vstinner@python.org> wrote:
I dislike the Tier 1 rule "All core developers are responsible to keep these platforms, and thus
main, working."In my experience, "Everyone is reponsible" means in practice "nobody is responsible".
I don't think that applies here as you shouldn't even be merging a PR if it breaks CI for these platforms. And if CI isn't good enough then we should fix that.
If you still want a point of contact for those platforms then we can talk about that, but I wouldn't expect the listed folks to be as critical on those platforms to keep things functioning like they are for a tier 2 being supported by a buildbot post-merge.
Or put another way, tier 1 platforms are so critical we can't be expected to be dropped if someone isn't being responsive to questions, unlike tier 2 where we would probably drop a platform if folks weren't responsive enough.
IMO you must also put two names in front of each platform. Otherwise, nobody will fix them when it will be broken, and the best that we will be able to do is to just revert the change breaking the CI which prevents adding new features just because nobody wants to fix the CI.
Sometimes, a broken CI is unrelated to a Python change. Things break, *all the time*, for many various reasons including vacuum cleaners (*)!
But tier 1 is the CI we run on PRs, not in the Buildbot fleet.
(*) https://mail.python.org/archives/list/python-buildbots@python.org/message/27...
Victor
On Fri, Mar 25, 2022 at 7:04 PM Brett Cannon <brett@python.org> wrote:
On Fri, Mar 25, 2022 at 4:23 AM Victor Stinner <vstinner@python.org> wrote:
I dislike the Tier 1 rule "All core developers are responsible to keep these platforms, and thus
main, working."In my experience, "Everyone is reponsible" means in practice "nobody is responsible".
I don't think that applies here as you shouldn't even be merging a PR if it breaks CI for these platforms. And if CI isn't good enough then we should fix that. (...) But tier 1 is the CI we run on PRs, not in the Buildbot fleet.
Oh ok.
There is an old debate about differences between GitHub Actions and Buildbots:
- Buildbots run the test suite with "-u all" option. On Windows, Python is built in debug mode.
- GHA uses "-u all,-cpu". On Windows, Python is built in release mode (I think that changed last change after the 3rd buildbot failure not catched by GHA but buildbots).
A small number of regressions are not catched by GHA because of these minor differences. It's a trade-off to keep the workflow efficient (be able to merge a PR as soon as possible).
I'm fine with this trade-off. But we must keep an eye on buildbots, otherwise more changes are merged on top of the change introducing the regression.
--
If you consider that GHA are enough to prevent regressions for Tier 1, does it mean that the "macOS" job must become mandatory? It's a x86_64 platform. In my experience, this job is too slow and less reliable than other GHA jobs. Maybe macOS should be pushed to Tier 2. Fixing all macOS before a Python release is fine. But during the devcycle, sometimes there are no enough available core devs to fix macOS specific issues. Correct me if I'm wrong. I'm talking about the strong Tier 1 requirements about the short delay to fix a regression, or revert.
Victor
Night gathers, and now my watch begins. It shall not end until my death.
On 3/26/2022 5:11 PM, Victor Stinner wrote:
- Buildbots run the test suite with "-u all" option. On Windows, Python is built in debug mode.
- GHA uses "-u all,-cpu". On Windows, Python is built in release mode (I think that changed last change after the 3rd buildbot failure not catched by GHA but buildbots).
Correct, except it changed because it's the third time a regression was caught by *humans*, and not by either buildbots or CI, and the regression would have been caught by preexisting assert statements that only ran on Windows. In other words, the exact reason that debug builds exist and should be used for first pass testing.
I put my name down for Windows ARM64, but I'm probably the only person on the team with hardware access right now (unless someone has bought something and never mentioned it...). Once VMs are available, I'm sure we'll be able to cover it more easily, and for the most part it's identical to the other Windows platforms anyway - the OS does a very good job of hiding the differences.
Cheers, Steve
On Sat, Mar 26, 2022 at 10:11 AM Victor Stinner <vstinner@python.org> wrote:
On Fri, Mar 25, 2022 at 7:04 PM Brett Cannon <brett@python.org> wrote:
On Fri, Mar 25, 2022 at 4:23 AM Victor Stinner <vstinner@python.org>
wrote:
I dislike the Tier 1 rule "All core developers are responsible to keep these platforms, and thus
main, working."In my experience, "Everyone is reponsible" means in practice "nobody is responsible".
I don't think that applies here as you shouldn't even be merging a PR if it breaks CI for these platforms. And if CI isn't good enough then we should fix that. (...) But tier 1 is the CI we run on PRs, not in the Buildbot fleet.
Oh ok.
There is an old debate about differences between GitHub Actions and Buildbots:
- Buildbots run the test suite with "-u all" option. On Windows, Python is built in debug mode.
- GHA uses "-u all,-cpu". On Windows, Python is built in release mode (I think that changed last change after the 3rd buildbot failure not catched by GHA but buildbots).
A small number of regressions are not catched by GHA because of these minor differences. It's a trade-off to keep the workflow efficient (be able to merge a PR as soon as possible).
I'm fine with this trade-off. But we must keep an eye on buildbots, otherwise more changes are merged on top of the change introducing the regression.
--
If you consider that GHA are enough to prevent regressions for Tier 1, does it mean that the "macOS" job must become mandatory? It's a x86_64 platform. In my experience, this job is too slow and less reliable than other GHA jobs. Maybe macOS should be pushed to Tier 2. Fixing all macOS before a Python release is fine. But during the devcycle, sometimes there are no enough available core devs to fix macOS specific issues. Correct me if I'm wrong. I'm talking about the strong Tier 1 requirements about the short delay to fix a regression, or revert.
We can talk about it, but I personally wait until the macOS runs complete. I also hope that once merge queues <https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/using-a-merge-queue> go public (or we ask to get into the private beta) that it will help with any availability issues we have with macOS.
Thanks to Petr, and Victor, the platforms that are still looking for a total of two maintainers over at https://github.com/python/peps/pull/2442/files are:
- arch64-apple-darwin clang
- aarch64-linux-gnu glibc, clang (Victor is already listed)
- aarch64-windows-msvc
- powerpcle-linux-gnu glibc, clang
- s390x-linux-gnu glibc, gcc
- s390x-linux-gnu glibc, clang
- x86_64-linux-gnu glibc, clang (Victor is already listed)
- x86_64-unknown-freebsd BSD libc, cc (Victor is already listed)
On Thu, Mar 24, 2022 at 12:37 PM Brett Cannon <brett@python.org> wrote:
Based on the positive feedback that I've gotten on this and the only other suggestion was maybe bringing back tier 3 to represent, "being actively worked on" support (which i think we can add later if we feel it's worth it), I'm ready to ask folks to please start sending review suggestions on https://github.com/python/peps/pull/2442 to add yourself as supporting a platform (see https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/re... if you don't know what I mean by "review suggestion").
I believe at least Victor is currently out at the moment, so I'm not planning to rush this out and start removing platforms that lack two people and merging this PR, but I also don't want to put it off either. As a reminder, the platforms looking for declared support as a tier 2 platform are:
- arch64-apple-darwin clang
- aarch64-linux-gnu glibc, gcc
- aarch64-linux-gnu glibc, clang
- aarch64-windows-msvc
- powerpcle-linux-gnu glibc, gcc
- powerpcle-linux-gnu glibc, clang
- s390x-linux-gnu glibc, gcc
- s390x-linux-gnu glibc, clang
- x86_64-linux-gnu glibc, clang
- x86_64-unknown-freebsd BSD libc, cc
Tier 1 is taken care of:
- i686-windows-msvc
- x86_64-windows-msvc
- x86_64-apple-darwin BSD libc, clang
- x86_64-linux-gnu glibc, gcc
On Thu, Mar 17, 2022 at 5:56 PM Brett Cannon <brett@python.org> wrote:
After considering everyone's feedback, here are my proposed explanations for the tiers.
Tier 1
CI failures < https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>__ block releases.- Changes which would break the
mainbranch are not allowed to be merged; any breakage may be reverted immediately.- All core developers are responsible to keep these platforms, and thus
main, working.- Promotion to this tier requires team consensus/SC approval.
Tier 2
- Must have a reliable buildbot.
- At least **two** core developers are signed up to support the platform.
- Changes which break any of these platforms are to be fixed or reverted within 24 hours.
- Failures on these platforms block a release.
- Promotion to this tier requires consensus/SC approval.
All other platforms
Support for a platform may be partial within the code base, such as from active development around platform support or accidentally. Code changes to platforms not listed in the above tiers may rejected or removed from the code base without a deprecation process if they cause a maintenance burden or obstruct general improvements.
Platforms not listed here may be supported by the wider Python community in some way. If your desired platform is not listed above, please perform a search online to see if someone is already providing support in some form.
I have a draft PR up at https://github.com/python/peps/pull/2442 which can be previewed at https://pep-previews--2442.org.readthedocs.build/pep-0011/ (makes reading the table much easier). I made the platforms list the platform triple, libc, and compiler **without** version details.
Once I have buy-in for the above I will explicitly ask folks to send review comments to that PR to add themselves to the platforms they are willing to support, and then drop any which lack two core developers (warnings to the Fedora/RH folks: most of those platforms are listed are using Fedora buildbots, so it might be up to you 😉). I did drop powerpc-linux-gnu from the list as that buildbot has not successfully built in quite some time (powerpcle seems fine).
On Mon, Mar 14, 2022 at 5:35 PM Gregory P. Smith <greg@krypto.org> wrote:
On Mon, Mar 14, 2022 at 11:43 AM Marc-Andre Lemburg <mal@egenix.com> wrote:
On 14.03.2022 19:34, Brett Cannon wrote:
Greg proposed something like "Code changes to support platforms beyond tier1 or tier2 may be rejected, broken, or removed from the CPython codebase without notice if they cause a maintenance burden for tier1&2 or obstruct general improvements." and drop the concept of tier 3. Does that work for you?
Almost :-) I don't understand the "without notice". I guess Greg meant "without deprecation process". Removal of support code should be discussed on a ticket and then listed in PEP 11 and mentioned in the NEWS file, as usual.
I guess I was trying to convey that we may not even have a way to know that we're breaking something on a non-tier1/2 platform anyways so "without notice" was just me trying to set people's expectations. We don't go out of our way to _try_ and break things most of the time. "without a deprecation process" is also reasonable wording. Feel free to adopt those words.
Ideally we try to have discussion somewhere relevant when we _know_ we'd intentionally be removing support for something (for example of why: See the debacle that happened when dropping Solaris support was proposed).
-gps
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 14 2022)
> Python Projects, Coaching and Support ... https://www.egenix.com/ > Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/S... Code of Conduct: https://www.python.org/psf/codeofconduct/
On Mar 25, 2022, at 15:32, Brett Cannon <brett@python.org> wrote:
Thanks to Petr, and Victor, the platforms that are still looking for a total of two maintainers over at https://github.com/python/peps/pull/2442/files are: • arch64-apple-darwin clang [...]
I added this comment to the PR:
If x86_64-apple-darwin is a Tier 1 platform, then this must be as well. As of today, nearly all Macs being manufactured by Apple are of this architecture (i.e. Apple Silicon) and Apple has made clear that the few remaining legacy Intel-based Macs still being offered will be replaced in the near future (likely by the end of 2022). So, eventually x86_64-apple-darwin will fade in importance as older Macs are retired but that will take many years.
-- Ned Deily nad@python.org -- []
On Fri, Mar 25, 2022 at 1:18 PM Ned Deily <nad@python.org> wrote:
On Mar 25, 2022, at 15:32, Brett Cannon <brett@python.org> wrote:
Thanks to Petr, and Victor, the platforms that are still looking for a total of two maintainers over at https://github.com/python/peps/pull/2442/files are: • arch64-apple-darwin clang [...]
I added this comment to the PR:
If x86_64-apple-darwin is a Tier 1 platform, then this must be as well.
We realistically can't as we simply don't have the CI for arch64-apple-darwin based on the definition of tier 1. Otherwise we would all have to run every PR against the buildbot fleet just to test against Apple Silicon.
As of today, nearly all Macs being manufactured by Apple are of this architecture (i.e. Apple Silicon) and Apple has made clear that the few remaining legacy Intel-based Macs still being offered will be replaced in the near future (likely by the end of 2022). So, eventually x86_64-apple-darwin will fade in importance as older Macs are retired but that will take many years.
Yep, and my hope is we will have CI that can run on Apple Silicon at some point which will let us promote the platform, but until then it's not at the same level as the x64 support.
On Fri, Mar 25, 2022 at 8:32 PM Brett Cannon <brett@python.org> wrote:
Thanks to Petr, and Victor, the platforms that are still looking for a total of two maintainers over at https://github.com/python/peps/pull/2442/files are:
arch64-apple-darwin clang aarch64-linux-gnu glibc, clang (Victor is already listed) aarch64-windows-msvc powerpcle-linux-gnu glibc, clang s390x-linux-gnu glibc, gcc s390x-linux-gnu glibc, clang
FWIW, I'm not listing myself for s390x. While fixing Python for mainframes is part of my job at Red Hat, I don't have immediate access to such machines and can't promise timely fixes. When I (or Victor or someone else) comes up with a fix, we'll of course want to contribute it to CPython, but I think Tier 3 is fine for that. Usually these fixes *make Python conform better to the C standard*, e.g. avoiding endianness/bit-pattern assumptions. I assume such fixes should be welcome regardless of platform. But, if we don't have a big-endian arch in the 2 tiers, endian-specific code does “cause a maintenance burden or obstruct general improvements”. Same for e.g. code that relies on “common” implementation details in malloc or something like that.
Should the PEP explicitly say that fixing deviations from standard C is welcome, even if they don't manifest on the tiered arches?
On Mon, Mar 28, 2022 at 7:09 AM Petr Viktorin <encukou@gmail.com> wrote:
On Fri, Mar 25, 2022 at 8:32 PM Brett Cannon <brett@python.org> wrote:
Thanks to Petr, and Victor, the platforms that are still looking for a
total of two maintainers over at https://github.com/python/peps/pull/2442/files are:
arch64-apple-darwin clang aarch64-linux-gnu glibc, clang (Victor is already listed) aarch64-windows-msvc powerpcle-linux-gnu glibc, clang s390x-linux-gnu glibc, gcc s390x-linux-gnu glibc, clang
FWIW, I'm not listing myself for s390x. While fixing Python for mainframes is part of my job at Red Hat, I don't have immediate access to such machines and can't promise timely fixes. When I (or Victor or someone else) comes up with a fix, we'll of course want to contribute it to CPython, but I think Tier 3 is fine for that. Usually these fixes *make Python conform better to the C standard*, e.g. avoiding endianness/bit-pattern assumptions. I assume such fixes should be welcome regardless of platform. But, if we don't have a big-endian arch in the 2 tiers, endian-specific code does “cause a maintenance burden or obstruct general improvements”. Same for e.g. code that relies on “common” implementation details in malloc or something like that.
Should the PEP explicitly say that fixing deviations from standard C is welcome, even if they don't manifest on the tiered arches?
I don't think so. That's simply a compatibility thing that we have always done regardless of platforms. It's basic code health to adhere to the C standard for us.
I will give everyone another week, so until Friday, April 8th, to submit review changes to https://github.com/python/peps/pull/2442/ . Below is the list of platforms with stable buildbots that are lacking two core devs willing to be on the hook for helping support the platforms.
- aarch64-windows-msvc (Steve is already listed)
- powerpcle-linux-gnu glibc, clang
- s390x-linux-gnu glibc, gcc
- s390x-linux-gnu glibc, clang
- x86_64-linux-gnu glibc, clang (Victor is already listed)
- x86_64-unknown-freebsd BSD libc, cc (Victor is already listed)
On Fri, Mar 25, 2022 at 12:32 PM Brett Cannon <brett@python.org> wrote:
Thanks to Petr, and Victor, the platforms that are still looking for a total of two maintainers over at https://github.com/python/peps/pull/2442/files are:
- arch64-apple-darwin clang
- aarch64-linux-gnu glibc, clang (Victor is already listed)
- aarch64-windows-msvc
- powerpcle-linux-gnu glibc, clang
- s390x-linux-gnu glibc, gcc
- s390x-linux-gnu glibc, clang
- x86_64-linux-gnu glibc, clang (Victor is already listed)
- x86_64-unknown-freebsd BSD libc, cc (Victor is already listed)
On Thu, Mar 24, 2022 at 12:37 PM Brett Cannon <brett@python.org> wrote:
Based on the positive feedback that I've gotten on this and the only other suggestion was maybe bringing back tier 3 to represent, "being actively worked on" support (which i think we can add later if we feel it's worth it), I'm ready to ask folks to please start sending review suggestions on https://github.com/python/peps/pull/2442 to add yourself as supporting a platform (see https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/re... if you don't know what I mean by "review suggestion").
I believe at least Victor is currently out at the moment, so I'm not planning to rush this out and start removing platforms that lack two people and merging this PR, but I also don't want to put it off either. As a reminder, the platforms looking for declared support as a tier 2 platform are:
- arch64-apple-darwin clang
- aarch64-linux-gnu glibc, gcc
- aarch64-linux-gnu glibc, clang
- aarch64-windows-msvc
- powerpcle-linux-gnu glibc, gcc
- powerpcle-linux-gnu glibc, clang
- s390x-linux-gnu glibc, gcc
- s390x-linux-gnu glibc, clang
- x86_64-linux-gnu glibc, clang
- x86_64-unknown-freebsd BSD libc, cc
Tier 1 is taken care of:
- i686-windows-msvc
- x86_64-windows-msvc
- x86_64-apple-darwin BSD libc, clang
- x86_64-linux-gnu glibc, gcc
On Thu, Mar 17, 2022 at 5:56 PM Brett Cannon <brett@python.org> wrote:
After considering everyone's feedback, here are my proposed explanations for the tiers.
Tier 1
CI failures < https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted>__ block releases.- Changes which would break the
mainbranch are not allowed to be merged; any breakage may be reverted immediately.- All core developers are responsible to keep these platforms, and thus
main, working.- Promotion to this tier requires team consensus/SC approval.
Tier 2
- Must have a reliable buildbot.
- At least **two** core developers are signed up to support the platform.
- Changes which break any of these platforms are to be fixed or reverted within 24 hours.
- Failures on these platforms block a release.
- Promotion to this tier requires consensus/SC approval.
All other platforms
Support for a platform may be partial within the code base, such as from active development around platform support or accidentally. Code changes to platforms not listed in the above tiers may rejected or removed from the code base without a deprecation process if they cause a maintenance burden or obstruct general improvements.
Platforms not listed here may be supported by the wider Python community in some way. If your desired platform is not listed above, please perform a search online to see if someone is already providing support in some form.
I have a draft PR up at https://github.com/python/peps/pull/2442 which can be previewed at https://pep-previews--2442.org.readthedocs.build/pep-0011/ (makes reading the table much easier). I made the platforms list the platform triple, libc, and compiler **without** version details.
Once I have buy-in for the above I will explicitly ask folks to send review comments to that PR to add themselves to the platforms they are willing to support, and then drop any which lack two core developers (warnings to the Fedora/RH folks: most of those platforms are listed are using Fedora buildbots, so it might be up to you 😉). I did drop powerpc-linux-gnu from the list as that buildbot has not successfully built in quite some time (powerpcle seems fine).
On Mon, Mar 14, 2022 at 5:35 PM Gregory P. Smith <greg@krypto.org> wrote:
On Mon, Mar 14, 2022 at 11:43 AM Marc-Andre Lemburg <mal@egenix.com> wrote:
On 14.03.2022 19:34, Brett Cannon wrote:
Greg proposed something like "Code changes to support platforms beyond tier1 or tier2 may be rejected, broken, or removed from the CPython codebase without notice if they cause a maintenance burden for tier1&2 or obstruct general improvements." and drop the concept of tier 3. Does that work for you?
Almost :-) I don't understand the "without notice". I guess Greg meant "without deprecation process". Removal of support code should be discussed on a ticket and then listed in PEP 11 and mentioned in the NEWS file, as usual.
I guess I was trying to convey that we may not even have a way to know that we're breaking something on a non-tier1/2 platform anyways so "without notice" was just me trying to set people's expectations. We don't go out of our way to _try_ and break things most of the time. "without a deprecation process" is also reasonable wording. Feel free to adopt those words.
Ideally we try to have discussion somewhere relevant when we _know_ we'd intentionally be removing support for something (for example of why: See the debacle that happened when dropping Solaris support was proposed).
-gps
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 14 2022)
>> Python Projects, Coaching and Support ... https://www.egenix.com/ >> Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/S... Code of Conduct: https://www.python.org/psf/codeofconduct/
On Fri, Apr 1, 2022 at 12:25 AM Brett Cannon <brett@python.org> wrote:
powerpcle-linux-gnu glibc, clang
This one has 2 core devs in the PR: "Petr Viktorin, Victor Stinner".
s390x-linux-gnu glibc, gcc s390x-linux-gnu glibc, clang x86_64-unknown-freebsd BSD libc, cc (Victor is already listed)
I started a new thread proposing to add a separated Tier 3 for these platforms.
Victor
Night gathers, and now my watch begins. It shall not end until my death.
On Fri, Apr 1, 2022 at 1:42 AM Victor Stinner <vstinner@python.org> wrote:
On Fri, Apr 1, 2022 at 12:25 AM Brett Cannon <brett@python.org> wrote:
powerpcle-linux-gnu glibc, clang
This one has 2 core devs in the PR: "Petr Viktorin, Victor Stinner".
Oh wait, "Petr Viktorin, Victor Stinner" are for gcc, and this is is for clang, sorry.
For clang, you can put me my name. But maybe this one should be removed (or moved to Tier 3 if we consider adding it) if there is no second volunteer core dev.
RHEL and Fedora packages are built by GCC. Fedora only recently allowed some specific packages, like Firefox, to be built by clang. But IMO it's useful to look at clang warnings and errors, they usually spot interesting portability issues and real bugs.
All FreeBSD packages are built with clang.
Victor
Night gathers, and now my watch begins. It shall not end until my death.
On 11. 03. 22 0:35, Brett Cannon wrote:
I brought this up on python-dev at https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP3... <https://mail.python.org/archives/list/python-dev@python.org/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
XXXplaceholders 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
mainbranch 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?
On Fri, Mar 11, 2022 at 1:26 AM Petr Viktorin <encukou@gmail.com> wrote:
On 11. 03. 22 0:35, Brett Cannon wrote:
I brought this up on python-dev at
https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP3...
, 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
XXXplaceholders 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
mainbranch 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-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?
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?
On 11. 03. 22 19:30, Brett Cannon wrote:
On Fri, Mar 11, 2022 at 1:26 AM Petr Viktorin <encukou@gmail.com <mailto:encukou@gmail.com>> wrote:
On 11. 03. 22 0:35, Brett Cannon wrote: > I brought this up on python-dev at > https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ <https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/> > <https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP3V7KHNPYWE6BEQD5ASES2NLV/ <https://mail.python.org/archives/list/python-dev@python.org/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> > <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-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?Perhaps; I was tempted to do that, but Christian requested the triples.
The triples are fine, but the "glibc 2.31" is too specific. Especially in the Tier 2 list.
[...]> 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?
I think the other thread in the conversation makes this moot, but I'd drop the Buildbot requirement for tier 3. It's enough that there's a core dev interested in bringing a platform like WASM or Android up to speed.
On 11/03/2022 00.35, Brett Cannon wrote:
I brought this up on python-dev at https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP3... <https://mail.python.org/archives/list/python-dev@python.org/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
XXXplaceholders 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
On Fri, Mar 11, 2022 at 1:38 AM Christian Heimes <christian@python.org> wrote:
On 11/03/2022 00.35, Brett Cannon wrote:
I brought this up on python-dev at
https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP3...
, 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
XXXplaceholders 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 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
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
On Fri, Mar 11, 2022 at 5:04 PM Victor Stinner <vstinner@python.org> wrote:
Hi Brett,
You can put my name as Contact of all Fedora and RHEL platforms.
Note: Fedora "Rawhide" is the rolling release and it's common that these buildbots are broken by kernel, compiler or glibc updates, rather than actual 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.
Christian had suggested/asked for that. So are people okay dropping the glibc version and instead documenting that it's testing glibc instead of e.g. musl?
-Brett
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.
Do we want to mention compilers in this? And is it just at the extent of which compiler but w/o a version number?
On 14/03/2022 19.37, Brett Cannon wrote:
On Fri, Mar 11, 2022 at 5:04 PM Victor Stinner <vstinner@python.org <mailto:vstinner@python.org>> wrote:
Hi Brett, You can put my name as Contact of all Fedora and RHEL platforms. Note: Fedora "Rawhide" is the rolling release and it's common that these buildbots are broken by kernel, compiler or glibc updates, rather than actual 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.Christian had suggested/asked for that. So are people okay dropping the glibc version and instead documenting that it's testing glibc instead of e.g. musl?
Looks like I was not communicating my intention clearly. I don't want to list libc ABI and Kernel ABI of every targeted distro. Instead I would like to include only the glibc version of the oldest manylinux wheel standard that is supported by PyPI.
glibc has a strong forward compatibility guarantee. If something works with glibc 2.17, then it will also work with 2.34. A minimum glibc version sets the minimum feature set that we can rely on. If we say that Python is tested with glibc 2.17 and Kernel ABI 3.10 (CentOS 7), then we set CentOS 7 a baseline for users that also covers Debian Oldstable.
glibc and Kernel ABI are relevant for some features like getrandom() syscall, memfd_create, and similar.
Christian
On Mon, Mar 14, 2022 at 12:59 PM Christian Heimes <christian@cheimes.de> wrote:
On 14/03/2022 19.37, Brett Cannon wrote:
On Fri, Mar 11, 2022 at 5:04 PM Victor Stinner <vstinner@python.org <mailto:vstinner@python.org>> wrote:
Hi Brett, You can put my name as Contact of all Fedora and RHEL platforms. Note: Fedora "Rawhide" is the rolling release and it's common that these buildbots are broken by kernel, compiler or glibc updates, rather than actual 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 thatit's
worth it to mention the glibc version. Fedora is released every 6 months and the glibc version is updated at each Fedora release.Christian had suggested/asked for that. So are people okay dropping the glibc version and instead documenting that it's testing glibc instead of e.g. musl?
Looks like I was not communicating my intention clearly. I don't want to list libc ABI and Kernel ABI of every targeted distro. Instead I would like to include only the glibc version of the oldest manylinux wheel standard that is supported by PyPI.
That concept doesn't exist anymore thanks to perennial manylinux support: https://peps.python.org/pep-0600/ .
glibc has a strong forward compatibility guarantee. If something works with glibc 2.17, then it will also work with 2.34. A minimum glibc version sets the minimum feature set that we can rely on. If we say that Python is tested with glibc 2.17 and Kernel ABI 3.10 (CentOS 7), then we set CentOS 7 a baseline for users that also covers Debian Oldstable.
glibc and Kernel ABI are relevant for some features like getrandom() syscall, memfd_create, and similar.
Since the glibc version support is now embedded as part of the tag for wheels on Linux, I don't think we can really specify a minimum anymore. In that case it probably comes down to simply saying a platform using glibc for the libc implementation is enough.
-Brett
On 11 Mar 2022, at 00:35, Brett Cannon <brett@python.org> wrote:
I brought this up on python-dev at https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP3... <https://mail.python.org/archives/list/python-dev@python.org/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
XXXplaceholders 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
mainbranch 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 <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 <https://buildbot.python.org/all/#/builders/725> XXX aarch64-linux-gnu glibc XXX [fedora-stable]_ https://buildbot.python.org/all/#/builders/125 <https://buildbot.python.org/all/#/builders/125> XXX glibc 2.28 [RHEL8]_ https://buildbot.python.org/all/#/builders/529 <https://buildbot.python.org/all/#/builders/529> XXX aarch64-windows-msvc XXX https://buildbot.python.org/all/#/builders/729 <https://buildbot.python.org/all/#/builders/729> XXX powerpc64-linux-gnu glibc XXX https://buildbot.python.org/all/#/builders/237 <https://buildbot.python.org/all/#/builders/237> XXX powerpcle-linux-gnu glibc XXX https://buildbot.python.org/all/#/builders/90 <https://buildbot.python.org/all/#/builders/90> XXX s309x-linux-gnu glibc XXX https://buildbot.python.org/all/#/builders/223 <https://buildbot.python.org/all/#/builders/223> XXX glibc 2.28 [RHEL8]_ https://buildbot.python.org/all/#/builders/509 <https://buildbot.python.org/all/#/builders/509> XXX glibc 2.17 [RHEL7]_ https://buildbot.python.org/all/#/builders/179 <https://buildbot.python.org/all/#/builders/179> XXX x86_64-linux-gnu glibc 2.17 [RHEL7]_ https://buildbot.python.org/all/#/builders/15 <https://buildbot.python.org/all/#/builders/15> XXX x86_64-unknown-freebsd XXX https://buildbot.python.org/all/#/builders/172 <https://buildbot.python.org/all/#/builders/172> XXX ====================== ========================== ============================================== ========
.. [fedora-stable] XXX .. [RHEL8] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_8 <https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_8> .. [RHEL7] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm... <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
mainfor 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 ========================= ========================== ============================================== ======== wasm32-unknown-emscripten XXX XXX Brett Cannon, Christian Heimes wasm32-unknown-wasi XXX XXX Brett Cannon, Christian Heimes ========================= ========================== ============================================== ========
All other platforms
- Only code which either supports a higher-tier platform or is a general improvement may be checked in.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/K... Code of Conduct: https://www.python.org/psf/codeofconduct/
Currently the macOS installer would be in the “All other platforms” section, with a framework build that targets macOS 10.9 or later while building on macOS “latest”. What would be needed to add a stable buildbot that actively tests this build on macOS? To complicate things, I probably don’t have spare hardware that can be used for this.
Ronald —
Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/
I wonder if putting this into a PEP might be a little heavyweight in terms of making adjustments to the platform triples and their priorities? I perhaps think something that's a look aside table with a defined policy of how to move various triples up and down might work better?
On Fri, 11 Mar 2022, 10:36 am Brett Cannon, <brett@python.org> wrote:
I brought this up on python-dev at https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP3... , 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
XXXplaceholders 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
mainbranch 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/htm...
Tier 3
- Must have a stable buildbot.
- Code may be checked into
mainfor 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 ========================= ========================== ============================================== ======== wasm32-unknown-emscripten XXX XXX Brett Cannon, Christian Heimes wasm32-unknown-wasi XXX XXX Brett Cannon, Christian Heimes ========================= ========================== ============================================== ========
All other platforms
- Only code which either supports a higher-tier platform or is a general improvement may be checked in.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/K... Code of Conduct: https://www.python.org/psf/codeofconduct/
On Tue, Mar 29, 2022 at 12:40 AM Anthony Baxter <anthonybaxter@gmail.com> wrote:
I wonder if putting this into a PEP might be a little heavyweight in terms of making adjustments to the platform triples and their priorities? I perhaps think something that's a look aside table with a defined policy of how to move various triples up and down might work better?
If the SC is ultimately going to be the arbiter of consensus on the status of a platform, then a PEP is no less heavyweight than some other process. Plus I don't see this list fluctuating regularly, so I don't think this is any worse than e.g. the devguide.
-Brett
On Fri, 11 Mar 2022, 10:36 am Brett Cannon, <brett@python.org> wrote:
I brought this up on python-dev at https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP3... , 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
XXXplaceholders 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
mainbranch 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/htm...
Tier 3
- Must have a stable buildbot.
- Code may be checked into
mainfor 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 ========================= ========================== ============================================== ======== wasm32-unknown-emscripten XXX XXX Brett Cannon, Christian Heimes wasm32-unknown-wasi XXX XXX Brett Cannon, Christian Heimes ========================= ========================== ============================================== ========
All other platforms
- Only code which either supports a higher-tier platform or is a general improvement may be checked in.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/K... Code of Conduct: https://www.python.org/psf/codeofconduct/
FYI there are now tier labels for the buildbots and the links have been added to the PEP.
https://peps.python.org/pep-0011/#support-tiers Tier 2: https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Btier-2 Tier 3: https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Btier-3
(Tier 1 is covered by https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3... .)
On Thu, Mar 10, 2022 at 3:35 PM Brett Cannon <brett@python.org> wrote:
I brought this up on python-dev at https://mail.python.org/archives/list/python-dev@python.org/thread/ZPBSHENP3... , 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
XXXplaceholders 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
mainbranch 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/htm...
Tier 3
- Must have a stable buildbot.
- Code may be checked into
mainfor 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 ========================= ========================== ============================================== ======== wasm32-unknown-emscripten XXX XXX Brett Cannon, Christian Heimes wasm32-unknown-wasi XXX XXX Brett Cannon, Christian Heimes ========================= ========================== ============================================== ========
All other platforms
- Only code which either supports a higher-tier platform or is a general improvement may be checked in.
On 08/06/2022 21.21, Brett Cannon wrote:
FYI there are now tier labels for the buildbots and the links have been added to the PEP.
https://peps.python.org/pep-0011/#support-tiers <https://peps.python.org/pep-0011/#support-tiers> Tier 2: https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Btier-2 <https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Btier-2> Tier 3: https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Btier-3 <https://buildbot.python.org/all/#/builders?tags=%2B3.x&tags=%2Btier-3>
(Tier 1 is covered by https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3... <https://github.com/python/cpython/actions/workflows/build.yml?query=branch%3Amain+is%3Acompleted> .)
FYI, https://github.com/python/cpython/issues/93491 has landed. ./configure now checks and reports support tier level:
checking for PEP 11 support tier... x86_64-pc-linux-gnu/gcc has tier 1 (supported)
checking for PEP 11 support tier... wasm32-unknown-emscripten/clang is not supported ... Platform "wasm32-unknown-emscripten" with compiler "clang" is not supported by CPython core team, see https://peps.python.org/pep-0011/ for more information.
Christian
participants (13)
-
Anthony Baxter -
Brett Cannon -
Christian Heimes -
Christian Heimes -
Gregory P. Smith -
Marc-Andre Lemburg -
Ned Deily -
Paul Moore -
Petr Viktorin -
Ronald Oussoren -
Steve Dower -
Victor Stinner -
Zachary Ware