On Sun, Feb 21, 2021 at 12:28 PM Gregory P. Smith <g...@krypto.org> wrote:
> > On Sun, Feb 21, 2021 at 10:15 AM Christian Heimes <christ...@python.org> > wrote: > >> On 21/02/2021 13.47, glaub...@debian.org wrote: >> > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 >> platforms. There is no separate configure guard. All platforms that Rust >> can build for, are always enabled by default. No one in Rust keeps anyone >> from cross-compiling code for sparc64 or powerpcspe, for example. >> > >> > So if you want to copy Rust's mechanism, you should just leave it as is >> and not claim that users are being confused because "m68k" shows up in >> configure.ac. >> >> A --enable-unstable-platforms configure flag is my peace offer to meet >> you half way. You get a simple way to enable builds on untested >> platforms and we can clearly communicate that some OS and hardware >> platforms are not supported. >> > > I personally wouldn't want to maintain such a check in autoconf, but it'll > be an isolated thing on its own, that if you or someone else creates, will > do its job and not bother the rest of us. > If we add a compile flag to explicitly make people have to realize they are running on an unsupported platform then I think it should be a negation against an allowlist versus a blocklist to be more explicit about what we would take PRs for. > > I think just publishing our list of (1) supported, (2) best-effort > non-release-blocker quasi-supported, and (3) explicitly unsupported in a > policy doc is sufficient. But it's not like any of us are going to stop > someone from codifying that in configure.ac to require a flag. > I like the idea of making PEP 11 list what platforms *are* supported in some way, and being off that list means you're not. I also like the idea of having a tier 1 that will block a release and a tier 2 where we will accept PRs but it will in no way block releases. I also think who ends up on either of those tiers should be an SC problem. Based on how heated this thread has gotten there's obviously some emotional connection for some folks when it comes to whether a platform is supported or not and how that is handled. In that sense, letting the SC take on the burden of saying "no" makes sense. That doesn't mean PEP 11 wouldn't still list out the *minimum* requirements to add a platform, but I don't think it should be an automatic thing simply because a machine was donated and a hand was raised as e.g. #ifdefs have a cognitive cost. So, my suggestion is to update PEP 11 to: - List platforms that can block releases as a "tier 1" supported platform - List platforms that are best effort as "tier 2" and which will never hold up a release - All other platforms will need to manage their patchset externally and we will not accept PRs that are specifically for them - Specify what the *minimum* requirements are to add support for a platform to either tier - Have the SC manage what platforms can end up in what tier (and we can publish guidelines like conditional tier 2 to prove support exists, what is required to graduate to tier 1, removal from tiers, etc.)
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TKEG3OF4BIIVO56BQT37PJEVBLJZCUJL/ Code of Conduct: http://python.org/psf/codeofconduct/
