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.
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.
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 to add the label.
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.
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?
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.
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.
Seems that way, but it’s a spectrum. For example, sometimes we want to ignore “OEM” support status – see PEP-738#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.)
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.