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.