Front page | perl.perl5.porters |
Postings from May 2021
"platforms" and "support"
From: Nicholas Clark
May 18, 2021 12:00
"platforms" and "support"
Message ID: 20210518120004.GS16703@etla.org
What are we trying to achieve:
We have limited developer resources. Maintaining support for older platforms
isn't free. There's a direct cost - time spent dealing with them reduces
time that could be spent for the benefit of all users. There's an indirect
cost - needing to continue support certain older platforms can rule out
using newer APIs that would permit improvements.
But we don't want to drop platforms on a whim - there's a trade off here, so
we need to make an informed judgement call.
The questions we need to ask when considering actively dropping platform
* What do we sunset with this?
* What do we gain?
# What is a platform?
I realise that we don't even have a clear definition of this. I think that
we start with an (OS, toolchain) pair, so "MSVC on Win32" or "GNU toolchain
on HP-UX", and similar.
"Toolchain" is potentially a can of worms - the first obvious division is
"GNU make with vendor compiler" or "vendor make with gcc", but technically
all of make, compiler, assembler, linker and C library matter (eg MUSL vs
glibc) but usually you don't need that n-way complexity. (And if you really
care at some points it even got to threading model (eg Linux), dynamic
linker (eg AIX), object format (eg Linux), ABI and probably some more that I
forgot). But likely none of these matter for this document - if you can
support one, you can support all for that OS.
CPU is *unlikely* to matter - usually if a C compiler exists for an OS then
we could target everything Alpha to z-Series. (Is Apple's M1 the only
exception? And IIRC that wasn't the CPU per se, but the toolchain options)
So take (OS, toolchain), and then consider our Configure options. *Many*
things can be changed, but the two that matter are
* threaded / unthreaded
* 32 bit / 64 bit.
I assume that most *nix builds are intended to run on the same version that
they built on, but macOS and Win32 vendor toolchains seem to be able to
target earlier versions. What matters for our "platform" is the target
version, not the build version, and so upping the minimum compiler version
might implicitly sunset an OS version.
So I think our that "platform" is
1) OS (by version)
2) toolchain (by version)
3) threaded / unthreaded
4) 32 bit / 64 bit.
with that order representing how much flexibility we can offer.
# What do we mean "support"?
We think this is best expressed as tiers:
1) Best effort to make work — Works now. If broken, we want to fix.
2) Known to build — Works now. If broken, we’ll know. Likely accept fixes.
3) Code to build/work exists, status unknown — Status unknown. In danger of dropping to 4.
4) No code to support, such code would be rejected
If a platform in Tier 3 is relegated to Tier 4, we delete the code.
Similar to what Rust does, although their Tier 2 still requires a smoker.
So maybe this isn't quite right - if it doesn't smoke, how do we know its
OS security support is relevant to a platform's tier, but not essential.
As rjbs expressed it:
CASE A: If a million people are still writing new Perl code on BlubOS, it's
probably worth making at least some effort to keep it building. If they're
running smoke tests and contributing time to fix bugs, and if this isn't
causing problems for anything else, I think we should do that.
CASE B: If there appears to be a single user writing code in Perl on BlubOS,
and they can't write C and the support for BlubOS is making it hard to
reason about the code base because it's ifdef-rich, we should probably
immediately declare we're going to remove the code that makes BlubOS build
The discontinuance of security updates is going to be a force of its own
driving users off of the system, meaning we're much more likely to find them
in Case B than Case A.
(Of course there are middle grounds, like the apparent single user of a
long-dead platform who is willing to smoke test and provide patches, which
still won't be enough to make it worth keeping the build working if it gets
in the way of progress.)
Effectively our support boils down to no more/no less than
If it's in tier 1, we will not make a release where this does not work
(without serious extenuating circumstances.)
(as this includes monthly dev releases is not an empty promise)
This implies that to be *in* Tier 1, as well as a smoker, there also need to
be known people who can fix it.
To become a configuration with first-class support, first there must be an
active smoker on that platform. Then, there needs to be general agreement
among the committers that the configuration is important enough to block
stable releases when known broken.
So we put a list of these somewhere (perlport?) and pull requests to amend
the list are reviewed and applied based on what seems realistic.
As to "removing support", as rjbs expressed it:
I think that we'll want to have two basic go-to policies here:
* this thing has not worked in ages, nobody complained, and we are just
going to remove the illusion that it might work
* this thing worked, but we think it is no longer seeing any use, so we will
issue a big complaint when building for it and give it one full release
cycle for anybody to show up with a great reason why it should be spared.
"platforms" and "support"
by Nicholas Clark