Clarifying PEP 11 around dropping support

[brettcannon]

https://discuss.python.org/t/im-stepping-down-as-sponsor-of-emscripten/41064/6 has Pyodide asking how to interpret https://peps.python.org/pep-0011/#unsupporting-platforms and the fact it calls for building to fail to "potential users of the platform a chance to step forward and offer maintenance" while we have no concept of community support w/o a sponsor.

A couple of options that I can think of:

1. Take out the line about giving the community a chance to find support
2. Change it to say it's a chance to find a core dev sponsor
3. We don't require a build error, but we do require a notice in What's New

[gvanrossum]

I personally don't think we need to force a build error. Sure, it's likely in many cases that unsupported platforms will start developing build errors, and that's fine -- but at the same time there's a difference between "not supported" and "actively sabotaged". Given that most unsupported platforms have only a very small user base who care about Python, I doubt that we'll be inundated with bug reports. If an occasional one comes through, closing it with a reference to PEP 11 seems simple enough.

Given that the intended process is that a core dev sponsor must be found before support can be (re)instated, it makes sense to add a reminder to this section of the PEP.

[vstinner]

Emscripten is now supported in Tier-3. Can we close this issue @brettcannon?

[brettcannon]

Emscripten is now supported in Tier-3. Can we close this issue @brettcannon?

No because the base question still exists the next time a platform gets dropped.

[gpshead]

FWIW I'm in favor of just changing the wording to suggest the build warn at most if it is easy to do so for things that were once a tiered platform but no longer are. We clearly have a lot of unsupported non-tier / never-tiered platforms that people keep CPython working on without a need to patch out some extra-effort build failure.

[encukou]

It might be better to put calls for maintainers in the relevant release notes than in build output.

As I now see it, support promises -- ours or others' -- get added “on top” of what's in the repo itself. Release notes are fittingly specific to the CPython core team.