# Community support for a platform **URL:** \ **Category:** Core Workflow\ **Created:** [January 31, 2024, 9:13am UTC](https://discuss.python.org/t/community-support-for-a-platform/44621 "2024-01-31T09:13:55Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [January 31, 2024, 9:13am UTC](https://discuss.python.org/t/community-support-for-a-platform/44621/1 "2024-01-31T09:13:55Z")
Continuing the discussion from [Proposed update to PEP-11 on Unsupporting a platform (less draconian measures)](https://discuss.python.org/t/proposed-update-to-pep-11-on-unsupporting-a-platform-less-draconian-measures/44065/9): > [@Proposed update to PEP-11 on Unsupporting a platform (less draconian measures)](https://discuss.python.org/t/proposed-update-to-pep-11-on-unsupporting-a-platform-less-draconian-measures/44065/9): > > > [@Proposed update to PEP-11 on Unsupporting a platform (less draconian measures)](https://discuss.python.org/t/proposed-update-to-pep-11-on-unsupporting-a-platform-less-draconian-measures/44065/7): > > > > Like I wonder how many people know what platforms we do support even if we do happen to compile somewhere? Do they assume it’s officially supported? > > And does it matter to them? We handle/close issues based on whether a volunteer wants to work on them. IMO, PEP-11 is mostly a summary of what we want to work on, written for Python devs/triagers – so that you know who to bug for a particular platform, or whether you should “revert first and fix later” when something goes red. > > For users, there’s very little actionable information in PEP-11. > > > [@Proposed update to PEP-11 on Unsupporting a platform (less draconian measures)](https://discuss.python.org/t/proposed-update-to-pep-11-on-unsupporting-a-platform-less-draconian-measures/44065/7): > > > > I think it was also meant to see if more people would come forward to help support a platform. > > Trouble is, they did come forward, and asked what they should do to help support a platform. We have no good answer. And that’s fine, really – it’s OK to do what seems best, and only standardize after it happens a few times. But we should probably acknowledge that Emscripten is in this experimental phase, and do what’s best for it rather than take PEP-11 _too_ literally (and amend it whenever a detail needs changing). I’d like to figure out how “community support for a platform” should work. As a first step, I [asked people interested in Emscripten to list themselves on the Experts index](https://discuss.python.org/t/41064/20). IMO, we should ping them on Emscripten-related issues (as a courtesy at least), and the experts list is the perfect place to list who they are. Should there be a process for adding people there? (Or is there one that I missed?) Should we document/adjust what the experts index is? IMO: yes, eventually, but no need to rush that. To me this seems like a clear case of who _should_ be there, and since it’s an unsupported platform, IMO it’s pretty clear that it’s just a list of people who asked to be pinged. Adding people to the list is easy to revert. I plan to ask for forgiveness rather than permission. If I mess up, I’ll undo my mess. ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [January 31, 2024, 9:39am UTC](https://discuss.python.org/t/community-support-for-a-platform/44621/2 "2024-01-31T09:39:06Z")
Continuing the discussion from [Should we close issues for platforms not covered by PEP 11 or under active development?](https://discuss.python.org/t/should-we-close-issues-for-platforms-not-covered-by-pep-11-or-under-active-development/16437): How to handle issue triage for unsupported platforms? I propose: - Add the issue to the [Unsupported platforms project](https://github.com/orgs/python/projects/27/views/1) - Better: add an `OS-unsupported` label, which would add the issue to the project automatically. The _platform_ field would be unset (to be categorized within the project later). This would mean triagers don’t need to care about the GitHub project. I’ve opened [core-workflow#526](https://github.com/python/core-workflow/issues/526) to add the label. - Close it as _not planned_ ---
**Author:** ![erlendaasland](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/erlendaasland/32/4378_2.png) [@erlendaasland](https://discuss.python.org/u/erlendaasland)\ **Post date:** [January 31, 2024, 11:24am UTC](https://discuss.python.org/t/community-support-for-a-platform/44621/3 "2024-01-31T11:24:20Z")
> [@encukou](#): > > Close it as _not planned_ IIUC, in addition we’re not going to actively tear out support for unsupported platforms? ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [January 31, 2024, 11:42am UTC](https://discuss.python.org/t/community-support-for-a-platform/44621/4 "2024-01-31T11:42:31Z")
Right, plus I’m planning to merge trivial PRs like [gh-91962: Fix curses compilation on Solaris by kulikjak · Pull Request #91964 · python/cpython · GitHub](https://github.com/python/cpython/pull/91964/files) to `main`. At least until that becomes a burden – at that point, hopefully the path to a better process will be clearer. ---
**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\ **Post date:** [January 31, 2024, 7:21pm UTC](https://discuss.python.org/t/community-support-for-a-platform/44621/5 "2024-01-31T19:21:46Z")
> [@encukou](#): > > Adding people to the list is easy to revert. I plan to ask for forgiveness rather than permission. If I mess up, I’ll undo my mess. FWIW, there is precedent for listing non-core-team community members there who support sub-tier-3 platforms (e.g. Android, Solaris), as I believe we had a discussion about previously, so it would be in keeping with the existing status quo to add such people there for Emscripten as you’re proposing. > [@encukou](#): > > Add the issue to the [Unsupported platforms project](https://github.com/orgs/python/projects/27/views/1) > > - Better: add an `OS-unsupported` label, which would add the issue to the project automatically. The _platform_ field would be unset (to be categorized within the project later). This would mean triagers don’t need to care about the GitHub project. > I’ve opened [core-workflow#526](https://github.com/python/core-workflow/issues/526) to add the label. To me “unsupported platforms” that implies there’s not going to be any effort to support that platform, and that Python does not in fact offer practical support for it. Maybe `community-supported-platforms`, `unofficially-supported-platforms`, etc. would be a better name? > [@erlendaasland](#): > > IIUC, in addition we’re not going to actively tear out support for unsupported platforms? Seems to me there’s actually two categories of unsupported platforms: - Those that simply lack sufficient core dev resources and interest to officially support - Those are affirmatively unsupported due to being obsolescent/obsolete/no longer actively supported by the OEM, or otherwise per PEP 11 It seems worth reviewing and merging fixes for the former as community interest and volunteer bandwidth allows, we just don’t promise to do so, and giving reasonable consideration to avoid actively removing support if it is possible to avoid without a major tradeoff elsewhere (e.g. at the cost of just code complexity, a small amount of performance, etc.). By contrast, the latter don’t generally seem worth actively reviewing and merging bugs to fix support for in new versions, nor actively working around removing support for (e.g. increasing target API, SDK, etc. version) if there would be some tangible benefit. ---
**Author:** ![erlendaasland](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/erlendaasland/32/4378_2.png) [@erlendaasland](https://discuss.python.org/u/erlendaasland)\ **Post date:** [January 31, 2024, 7:46pm UTC](https://discuss.python.org/t/community-support-for-a-platform/44621/6 "2024-01-31T19:46:19Z")
I think `OS-unsupported` is fine as a `python/cpython` GitHub label. Perhaps we want to choose a less frightening name for the GitHub project, where such issues are (proposed to be) automatically shuffled. I guess we could also leave a friendly message on the issue, as part of this `OS-unsupported` automation, regarding the implications of marking an issue with `OS-unsupported`. ---
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [February 1, 2024, 8:59am UTC](https://discuss.python.org/t/community-support-for-a-platform/44621/7 "2024-02-01T08:59:52Z")
> [@CAM-Gerlach](#): > > Seems to me there’s actually two categories of unsupported platforms: Seems that way, but it’s a spectrum. For example, sometimes we want to ignore “OEM” support status – see [PEP-738#OS versions](https://peps.python.org/pep-0738/#os-versions) IMO, the answers are along the lines of what you said, but much more nuanced. The `OS-unsupported` label is meant for core devs: it’s OK to close/reject the issue if you want. At this point, I am not too interested in bikeshedding names that can be changed easily in the future, like the GH project. (Also, being _too_ approachable would amount to false advertising.) ---
**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\ **Post date:** [February 1, 2024, 10:32pm UTC](https://discuss.python.org/t/community-support-for-a-platform/44621/8 "2024-02-01T22:32:42Z")
> [@encukou](#): > > Seems that way, but it’s a spectrum. For example, sometimes we want to ignore “OEM” support status – see [PEP-738#OS versions](https://peps.python.org/pep-0738/#os-versions) > IMO, the answers are along the lines of what you said, but much more nuanced. Yup, I had that (and Apple’s also relatively aggressive support policy for macOS) in mind with “no longer actively supported by the OEM, or otherwise per PEP 11”, i.e. platforms that both were no longer supported by the OEM and didn’t have longer explicit support stated in PEP 11 (or other PEPs, etc). And yeah, its definitely a bit of a spectrum, rather than a black and white, and important to consider that nuance when making such decisions.