develooper Front page | perl.perl5.porters | Postings from May 2021

Re: "platforms" and "support"

Thread Previous | Thread Next
From:
H.Merijn Brand
Date:
May 18, 2021 13:18
Subject:
Re: "platforms" and "support"
Message ID:
20210518151759.4bce9416@pc09
On Tue, 18 May 2021 12:00:04 +0000, Nicholas Clark <nick@ccl4.org>
wrote:

> 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 support are:
> 
> * 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.

To nitpick, OS on ARCH. HP-UX runs on ia64 (Itanium) and PA-RISC2.
Linux (and others) runs on Intel and ARM (and others), AIX runs on
RISC. Maybe some even run on MIPS. IMHO the ARCH is more important
than the OS.

> "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
> 
  * architecture
> * threaded / unthreaded
> * 32 bit / 64 bit.
  * default / longdouble / quadmath

> 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

  0) Arch
> 1) OS (by version)
> 2) toolchain (by version)
> 3) threaded / unthreaded
> 4) 32 bit / 64 bit.
  5) default / longdouble / quadmath

> 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 health?
> 
> 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 at all.

The danger with case B is that that single person might be the one
releasing perl and perl code used by many more that do not know how to
cope with the problems and rely on this single person (payed or not)

> 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.)

Er, yes, them too, but at least we know how to contact them :)

> 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.

Note also that removing *future* support will never block these users
from fetching an older source tree where things still ought to work, so
we are not ruling them out from perl, just from updates to it.

also note that the old rotten OS's will likely not get any (security)
updates themselves, so if these new users require new features, it is
not bad to ask them to run it on something relatively new (as in not
hardware running an OS that has been deprecated for 20 years or more)

-- 
H.Merijn Brand  https://tux.nl   Perl Monger   http://amsterdam.pm.org/
using perl5.00307 .. 5.33        porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
                           

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About