After considering everyone's feedback, here are my proposed explanations for the tiers.
mainbranch are not allowed to be
merged; any breakage may be reverted immediately.
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 email@example.com wrote:
On Mon, Mar 14, 2022 at 11:43 AM Marc-Andre Lemburg firstname.lastname@example.org wrote:
On 14.03.2022 19:34, Brett Cannon wrote:
Greg proposed something like "Code changes to support platforms beyond
tier2 may be rejected, broken, or removed from the CPython codebase
notice if they cause a maintenance burden for tier1&2 or obstruct
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).
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Mar 14 2022)
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/
python-committers mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://email@example.com/message/S... Code of Conduct: https://www.python.org/psf/codeofconduct/