perlport is inconsistent and the policies regarding OS support unclear

[wchristian]

As of current, the only source of perl documentation and policies re "OS support" appears to be perlport.

Which raises a big question of: Where else are OS support policies documented?

Skimming perlport, it is notable that it is inconsistent.

• For example AmigaOS is not in the list of "Supported Platforms", but mentioned thoroughly in the document.
• There are also three "Supported Platforms" sections:
  • one of which has 5.8 in the title
  • one which doesn't, but describes perl 5.12
  • one which generally describes platforms and some of their details

Which raises the question of: Which platforms are actually documented as supported?

And then there is currently the assumption that "a platform is documented as supported means there is a requirement that we must keep new perl versions fully functional for it". However the "platforms" heading doesn't have language to this effect, and the two "supported platforms" headings say something that isn't a promise or a requirement, but reads as a plain observation of currently known fact.

As of (the Perl release ), the following platforms were able to build Perl from the standard source code distribution

Thus: What promises are actually made regarding OS support and where?

[wchristian]

This issue stems from:

• Remove EOL Windows Versions From Supported List. Remove EOL Windows Versions From Supported List. #18242

A cursory search of previous issues indicates as relevant:

• Supported platforms Supported platforms #14173
• when do we tidy perlport? when do we tidy perlport? #12426

[wchristian]

As per IRC:

@Grinnz> deprecation policy is in https://perldoc.perl.org/perlpolicy but there's not much about platform support, since there's no concept of deprecating a platform, just supporting it or not

[nrr]

I'd had some conversation privately with @wchristian about necessarily seeking OS vendor or ISV sponsorship when it comes to making sure that particular platforms are "for sure" supported (e.g., Linux/x86_64, macOS/x86_64, and Windows/x86_64), particularly if they include a Perl release by default in the base install. With resource availability being what it is, this seems both sustainable and what Perl needs to survive under its own weight.

Another thing that comes to mind is rustc and its explicit tiered platform support model. As you get deeper in the tiers, the more platforms are supported, but that work is undertaken with particular caveats. In particular, for tier 3 support, no official toolchain binaries are provided, nor is any integration testing performed, but you have availability of rustc and, in some cases, the standard library for oddball platforms like NetBSD/sparc and Haiku/i686. That is, naturally, assuming that you can live with the potential of rustc and std on those platforms to eat your cat and kill your data.

I feel like, barring productive conversation on full-out platform deprecation, this model could provide for a good foundation upon which both platform support policy can be defined in a way that makes almost everyone happy and the project management types among us can better sort out priorities for, e.g., TPF grant work.

[wchristian]

• For example AmigaOS is not in the list of "Supported Platforms", but mentioned thoroughly in the document.

@bjornhagstrom

If affiliated with os4depot can you clarify the status of support for that platform?

I wanna say more here, but i must quickly comment on this because: That point means extremely little, given there is no clearly identified authoritative "Supported Platforms" list. It's not there to call Amiga support into question, but to demonstrate how wildly inconsistent the document as of current is.

[richardleach]

Another thing that comes to mind is rustc and its explicit tiered platform support model.

That approach appeals, even if just to add some clarity to existing documentation, although the tiers probably don't directly map across. (Perl perhaps has plenty of what are near enough Tier 1 "guaranteed to work" platforms, loads of Tier 3 "codebase has support for, but which are not built or tested automatically, and may not work" platforms, but not much in the Tier 2 "guaranteed to build but not subject to automated testing" middle ground?)

It'd would also be a useful place to explicitly outline how people can help a platform get better support/move up a tier - e.g. through providing hardware for smoking/testing.

Tier 3 - or a "no hardware available, no user reports for years, danger of deprecation" Tier 4 - could also forewarn users of the potential for platform deprecation many perl releases in advance.

[khwilliamson]

Where are we on this PR?

[wchristian]

@khwilliamson it's an issue, not a PR. and so far i've asked 3 questions, and got some feedback to take into account regarding ought states, but no answers about the is state.

[Leont]

I think the sensible thing to do is to define different tiers of support. E.g. Tier 1 could mean "we actively support and test this platform" (e.g. Linux, Mac, Windows, FreeBSD), Tier 2 means "We try to support this platform but don't actively test it" (e.g. Minix), and maybe a Tier 3 "This once worked, patches welcome if it broke" (bunch of old unices).

[arc]

@Leont I think that sounds like a sensible approach in general. I'd add three things:

• We'll need to do the work of categorising platforms into those tiers (probably a day of work for someone familiar with the idiosyncrasies of multiple platforms, and the hoops Perl jumps through to support them; and then a review period for people to argue for their pet platform's tier being bumped)
• We should probably have a "tier ∞", meaning something like "we're not aware of anyone using Perl on this platform, and we're liable to delete support for it in the next release if nobody steps up to support it"
• It would be helpful for us to come up with some kind of guidance (even if not completely specific) for what tier a new platform should be in — when is it appropriate for us to consider a new platform, once its support is implemented, as being "tier 1"? (I'm thinking about the recent introduction of ARM-based Macs, for example.)

[Leont]

We'll need to do the work of categorising platforms into those tiers (probably a day of work for someone familiar with the idiosyncrasies of multiple platforms, and the hoops Perl jumps through to support them; and then a review period for people to argue for their pet platform's tier being bumped)

Tier 1 is simple to define: if we don't test it it shouldn't be there. If anyone wants to add it to the list, we ask them "will you ensure it will be tested"

Tier 2 is basically "if it breaks, can we reasonably fix it". The Minix regression in 5.30.0 was a good example of this. In practice this will include all living Unices not in tier 1.

Tier 3 is essentially "what else do we still have a hints/*.sh entry for". Which is a lot more than one would think before looking at it.

We should probably have a "tier ∞", meaning something like "we're not aware of anyone using Perl on this platform, and we're liable to delete support for it in the next release if nobody steps up to support it"

That seems reasonable.

[xenu]

What is a platform? This ticket has "OS" in the title, but it's only part of the equation - we also have to worry about compilers. It is especially important in the context of requiring C99, which is something many of us want.

Windows is IIRC the only platform where we explicitly list the supported compilers (in the makefile), on the other systems the situation is less clear.

[rjbs]

I suggested roughly this same thing on IRC, independently, but slightly differently.

I think that tiers make sense, and would lay them out like this:

Tier 1 is: will not make a release where this does not work without serious extenuating circumstances.

You can't put something in this tier without testing. Testing, though, does not put something in this tier. You can run your modified OS/2+msys test suite all you want, but if it stops passing, there is no guaranteed action. And this is sort of thing is why I don't really know that I think Leon's suggested "Tier 2" is useful as a distinct category. What does it mean that "we" "can" fix it? Will we? Who will? Is there a guarantee?

I think this is a bit more like, "When we get a bug report, there's a general sense that somebody might know how to fix it and probably we'll apply the patch if somebody says it helped and 'tier one' systems are not broken by it."

Then there's Aaron's "Tier Infinite". He says this is "we're liable to [make it not build on purpose] in the next release if nobody steps up to support it." Why would we do this? We'd do it because it's getting in the way, which will largely mean "there are a bunch of ifdefs cluttering things up and never being entered" or "to start supporting the new platform APIs for this we will need to add ifdefs that we will always enter."

So, to me, I think it works out like this:

1. We want a list of "we test this build and won't ship a breaking change" builds
2. We want a public list of "we plan to remove support", and probably a means to get in the configuring users face if they try to build on one
3. Everything else is bugfixes produced or applied on a best effort basis.
4. It would be great to make sure we can show the smoke history of platforms of interest.
5. When we say we want to "drop support" for something, it either means removing the "will not break" promise or adding the "we will remove" guarantee. We always specify which one it is.

❓

[Leont]

Tier 1 is: will not make a release where this does not work without serious extenuating circumstances.

That makes sense, yes

And this is sort of thing is why I don't really know that I think Leon's suggested "Tier 2" is useful as a distinct category. What does it mean that "we" "can" fix it? Will we? Who will? Is there a guarantee?

It's not a guarantee, but as a statement of intent I do think it's useful.

[rjbs]

I'll move this thread to p5p shortly for more comment, and I think we're good on means to move forward here…