Mailing List Archive

"platforms" and "support"
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.

"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
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 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.
Re: "platforms" and "support" [ In reply to ]
I think this also needs to be clear what we mean by "works": it seems
to be common enough that a smoker has consistent hard or intermittent
test failures, and rare that someone notices those and creates a ticket
for them.

I suspect a bunch of those have been classified by someone as "not so
big a problem that it's worth putting a bunch of effort into", but
if so I don't think we have a way of recording such a fact.

I suspect that "works" is probably tier-dependent - and may even need
more tiers - such that only the highest tier would be "a release would
expect _no_ test failures except in exceptional circumstances".

Hugo
Re: "platforms" and "support" [ In reply to ]
On Tue, 18 May 2021 12:00:04 +0000
Nicholas Clark <nick@ccl4.org> wrote:

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

Given that you've listed four numbered tiers, I think this policy could
be expanded a bit into some statements about the maximum rate of change
between those tiers. It might different in the upwards vs downwards
direction, but at least I think we'd want to give some minimum time
periods that any particular configuration can transition from 1->2,
2->3 and 3->4 (which don't have to be the same duration). Possibly
upwards too - I doubt users will complain if their platform's support
tier rises too fast, but maybe the developers expected to maintain it
would want a say on that too.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: "platforms" and "support" [ In reply to ]
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
Re: "platforms" and "support" [ In reply to ]
I think it is important that users do not actually get in trouble.

For example, if Perl 5.34 was known as the Perl having no significant
issues and working well(Perl language itself, Middlewares, CPAN modules).

We can say

"Due to our less resources, it is difficult to support your OS(or the old
version)."

"On the other hand, you can continue to use Perl 5.34 with taking the risk."

Do you think creating rules and definitions will work well in themes of
"platforms" and "support"?
Re: "platforms" and "support" [ In reply to ]
Taking all the messages, hopefully keeping attribution and context clear.
Re-ordering some to answer in what feels a more logical order:

On Wed, May 19, 2021 at 01:10:19PM +0900, Yuki Kimoto wrote:

> Do you think creating rules and definitions will work well in themes of
> "platforms" and "support"?

To "work well", I don't know for sure, but I'm guessing "yes",
or at least, it will make things better than what we have. Else I
wouldn't trying to clarify things.

> We can say
>
> "Due to our less resources, it is difficult to support your OS(or the old
> version)."
>
> "On the other hand, you can continue to use Perl 5.34 with taking the risk."

I don't think I was clear by what "support" meant. Your statements above
make sense in the typical "our product might have bugs"/"feature request"
sense. But "platform support" really means

1) Does it even build?
2) If so does it pass its own tests?

"You can continue to use Perl 5.34" is kind of irrelevant in the context
I meant. The context is "I can't even manage to compile 5.34.0 on my system"
There's not much "use" possible if it didn't even install.

So arguably in this below, "works now" needs to be clear that it meant
"builds and passes its own tests":

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



On Tue, May 18, 2021 at 01:23:30PM +0100, hv@crypt.org wrote:
> I think this also needs to be clear what we mean by "works": it seems
> to be common enough that a smoker has consistent hard or intermittent
> test failures, and rare that someone notices those and creates a ticket
> for them.
>
> I suspect a bunch of those have been classified by someone as "not so
> big a problem that it's worth putting a bunch of effort into", but
> if so I don't think we have a way of recording such a fact.

Yes, that's a good point, but I don't know how to address it, at least in
a sustainable way. I know from other projects that GitHub triggered
Continuous Integration can fail for most wonderfully spurious reasons, eg:

1) Azure Pipelines can't connect to GitHub
(Left hand of Microsoft can't find right hand of Microsoft. D'oh!)
2) They corrected one base Ubuntu build *not* to put about 24 extraneous
repositories in the apt config (including 3 seeming official Ubuntu
developer personal repositories) resulting in setup that pulled in a
particular dev library now getting a much older version

*Those* both appear as "just another build failure" despite:

1) There is nothing to do here - this should be a skip
2) This exposed a real bug, but the changeset that "found" it was good

I'm not in a position personally to track flaps in CI, and I'm not sure
what to even suggest to automate this.

> I suspect that "works" is probably tier-dependent - and may even need
> more tiers - such that only the highest tier would be "a release would
> expect _no_ test failures except in exceptional circumstances".

Yes, I'm wondering this, but if so I'm not sure what a meaning full split
is. Thinking about this we had found that the ideas we had were close to
what Rust had defined, and the Rust folks have thought about this a lot,
so it seemed viable to align our tiers with theirs.

I'm not averse to having "more" tiers, as long as each has useful
distinction. I *think* what we have now is

1) CI on every commit and dammit it shall pass tests
(your "expect _no_ test failures except ...")
2) CI on every commit but sometimes it fails tests
3) We test these platforms (manually?) before each dev release
4) We test these platforms (manually?) before each RC and stable release
5) We have direct access to these platforms, but don't usually test

[.above here, "we" can replicate bugs and work on them. Below here, you're on
your own]

6) Third parties report that it still works
7) ... more than a year ago
8) We seem to have code that claims it will work, but no confirmation

?) All of "we don't know" to "we know it won't because we took it out"

That's a lot of tiers. Is it useful?
Should the infinity tier be split into "purgatory" and "hell"
(well, maybe more "heathen" vs "excommunicated")
"we don't know, but good luck and patches welcome" vs "we took it out for
a reason that is still valid. You're welcome to maintain a personal fork"


On Tue, May 18, 2021 at 01:47:00PM +0100, Paul "LeoNerd" Evans wrote:
> Given that you've listed four numbered tiers, I think this policy could
> be expanded a bit into some statements about the maximum rate of change
> between those tiers. It might different in the upwards vs downwards
> direction, but at least I think we'd want to give some minimum time
> periods that any particular configuration can transition from 1->2,
> 2->3 and 3->4 (which don't have to be the same duration). Possibly
> upwards too - I doubt users will complain if their platform's support
> tier rises too fast, but maybe the developers expected to maintain it
> would want a say on that too.

Rust don't, and I'm assuming that they thought about this a lot more than
any of us have.

https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/target-tier-policy.md

A proposed new tier 1 target must be reviewed and approved by the
compiler team based on these requirements. In addition, the release team
must approve the viability and value of supporting the target. For a
tier 1 target, this will typically take place via a full RFC proposing
the target, to be jointly reviewed and approved by the compiler team and
release team.

In addition, the infrastructure team must approve the integration of the
target into Continuous Integration (CI), and the tier 1 CI-related
requirements. This review and approval may take place in a PR adding the
target to CI, by an infrastructure team member reporting the outcome of
a team discussion, or by including the infrastructure team in the RFC
proposing the target.

...

A tier 1 target may be demoted if it no longer meets these requirements
but still meets the requirements for a lower tier. Any proposal for
demotion of a tier 1 target requires a full RFC process, with approval
by the compiler and release teams. Any such proposal will be
communicated widely to the Rust community, both when initially proposed
and before being dropped from a stable release. A tier 1 target is
highly unlikely to be directly removed without first being demoted to
tier 2 or tier 3. (The amount of time between such communication and the
next stable release may depend on the nature and severity of the failed
requirement, the timing of its discovery, whether the target has been
part of a stable release yet, and whether the demotion or removal can be
a planned and scheduled action.)


They seem to be carefully vague here. It's not quite "We demand rigidly
defined areas of doubt and uncertainty!" but I'm figuring that they foresee
that they'd like the wiggle room to be able to say "oh crap, ..." in
exceptional cases where something (eg Lawyers) have suddenly made it
impossible to support a "platform" fully.

On Tue, May 18, 2021 at 03:17:59PM +0200, H.Merijn Brand wrote:
> 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.

Well, I called it "CPU" below, not "ARCH":

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

and I wrote why I *had* thought it wasn't important.

I was going to write "we don't have any assembly code in the source" but:

os2/os2.c: __asm__( "pushf\n"
os2/os2.c: __asm__( "pushf\n"

I suspect that OS2 is one of the few OSes left which we have code for that
only ever ran on one CPU. And it's probably dead.

But we (almost) don't have any assembler code in the core, we don't rely
on any libraries that are ARCH specific (such as FFI systems), and as
long as we get our size, alignment and endian stuff correct, we are going to
work just as well on sparc64 as ia64.

IIRC I've used HP-UX on both, Solaris on x86 and Sparc, OS X on all 3
VMS on Alpha and ia64, *BSD on lots, Linux on "many". And for all, unless
it's figuring out alignment bugs (which are not actually CPU specific),
the same OS always behaves the same, whereas you don't even notice if
it's the same CPU but on different OSes (eg ppc64 Linux versus AIX)

So at the level of "does it build" I really don't think that ARCH matters.

However, your list is correct:

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

because we need to consider Continuous Integration systems, and right now
I think that we *only* have these on x64_64.
(Any OS you like, as long as it's black)

Technically (3) there is untheaded/multiplicity/threaded
(as ithreads implies multiplicity)

Are there any other Configure options that change $Config{archname}?

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

I was quoting rjbs, and I think by "and they can't write C" he meant the
case that it's someone "consuming" our time and *expecting* us to do work
for them. If we're doing the work and willing to do the work, that's a
totally different matter.

Also, it think rjbs meant an "AND" relationship - all of the above
sub conditions. Basically someone saying "you should keep supporting CP/M
because you always did and I'm relying on it" when doing so for us is
all of

1) unpaid work
2) complicating everything else
3) stealing time from stuff we'd actually like to do


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

Yes, that's a fair point. If your OS is out of security support, you can't
be in the habit of wanting to "upgrade" that, because you simply can't.
So why are you then expecting to upgrade Perl.


We had the same sort of confused arguments some time ago, indirectly
forwarded to me. It was roughly "but they want to be able to build the
current Catalyst from CPAN and run in on 5.8.whatever". Implied IIRC was
"including new XS code from CPAN".

And my return question was "could you ask them why, if they are happy
to build XS modules from source, for code with no real guarantees, they
are not happy to build perl from source?"

The answer relayed back was roughly "they can't answer this and I think
we've given up trying to figure this out"


Nicholas Clark
Re: "platforms" and "support" [ In reply to ]
I wrote up some thoughts on this, which ended up in a Google doc so I could iterate with Nick and then Rik.

Some key points here:

• The consumers of this are end users of Perl, so we should try and keep it relatively simple.
• The aim for end users is to give them an indication of how reliable Perl is on a given platform, and how that might change in the future.
• For p5p, it should help us answer the question "if a given platform is broken, how much should we care?". Also if a new OS comes out (e.g. Fuchsia) it should help us think about how it might progress from "unknown" to "battle-tested".
• I think you should be able find out what tier your perl is on from `perl -v`.
• We need to think about how a given configuration moves up and down the levels, and what schedule that can happen on. I’ve got a diagram in the document below, which suggests one way of thinking about that.
• I started off more detailed and more specific, but after discussion ended up thinking we should aim for an MVP and only go beyond that if there’s a real driver for it.


You can see and comment on the document:
https://docs.google.com/document/d/1RdBT0T6c61yYlOhtcgU9RFHB0pxXcnEhDsdW8hRteOc/edit?usp=sharing

Neil
Re: "platforms" and "support" [ In reply to ]
2021-6-14 0:18 Neil Bowers <neilb@neilb.org> wrote

>
> - For p5p, it should help us answer the question "if a given platform
> is broken, how much should we care?". Also if a new OS comes out (e.g.
> Fuchsia) it should help us think about how it might progress from "unknown"
> to "battle-tested".
>
> Does p5p mean developers who port Perl to specific platforms?


>
> - I think you should be able find out what tier your perl is on from
> `perl -v`.
>
> Can you tell me more details about this. I can't understand the meanings.
tier is difficult word to understand for me.
Re: "platforms" and "support" [ In reply to ]
Gotta admit these questions are odd to me. I'm not currently in any of these situations for Perl, but the answers seem obvious to me.

On Fri, 28 May 2021 10:12:10 +0200, Nicholas Clark <nick@ccl4.org> wrote:

> Yes, that's a fair point. If your OS is out of security support, you can't
> be in the habit of wanting to "upgrade" that, because you simply can't.
> So why are you then expecting to upgrade Perl.

1. Because upgrading an *Operating System* is often a lot more work than replacing one component like Perl. Often prohibitively so. Even on linux people often stick with older versions because of this hurdle.

2. Sometimes an OS is abandoned but there is no useful replacement. For example i still update software on my PS Vita (a platform with only a single OS) despite the fact that the last time the OS saw a update that wasn't "block jailbreaks" was 2015. Similarly the Amiga is still in active use by a lot of people despite the OS maker having disappeared decades ago.

> We had the same sort of confused arguments some time ago, indirectly
> forwarded to me. It was roughly "but they want to be able to build the
> current Catalyst from CPAN and run in on 5.8.whatever". Implied IIRC was
> "including new XS code from CPAN".
>
> And my return question was "could you ask them why, if they are happy
> to build XS modules from source, for code with no real guarantees, they
> are not happy to build perl from source?"

There may be unstated factors here, but uh ... because building and installing XS modules is fully automated in CPAN, while doing that with perl is a lot more daunting?

I've built and smoked perl on Windows and worked on that enough to get consistent green (not that anyone seemed to care), but i have no idea how to get from there to a working install and know i would need to learn more.

--
With regards,
Christian Walde
Re: "platforms" and "support" [ In reply to ]
Hi Kimoto-san,
> Can you tell me more details about this. I can't understand the meanings. tier is difficult word to understand for me.

I’ll try and describe the problem, and what we want to do.

Perl builds on many different operating systems (OSes). In the hints directory[1] you’ll find 82 hints files, for 70 different named OSes. Beyond a hints file, the OS may be checked with $^O in the testsuite, and there may be #ifdef’s in the C code. And maybe even an object file included in the Perl distribution!

But not all of those platforms are equal. Linux is widely used, and we put a lot of effort into making sure it builds and passes all tests. But for some OSes we don’t even know whether 5.34.0 will build on it – some hints files were last edited years ago.

Tiers

We want to define a number of "levels" or "tiers" of support. I’ll describe one possibility below, based on what’s in the document I shared[2].

The top tier is those platforms we’d consider "battled-tested", to borrow Curtis’s phrase: Linux, Windows, MacOS, and maybe one or two more? For these platforms we have reliable CI testing whenever something is committed to blead, and core developers have access to them. We consider Perl to be very reliable on these. We’d try and ensure good coverage on CPAN Testers as well, for example.

The next level down is pretty solid, but maybe one or two tests might fail, and maybe not all developer releases might get tested on these platforms. Maybe this is HP/UX, AIX, {Open,Free,Net}BSD, and others? We would like to consider these reliable.

And then we have operating systems where there appears to be support of some kind, but there’s no guarantee. OpenVOS (hints file vos.sh) might be here. Many of the hints files were submitted by a volunteer, and we hope that it works ok. Perl may or may not be reliable.

Any other platform is unknown. I.e. there’s no hint file and no support for it in the code or the tests. Google’s Fuchsia[3] is currently at this level. You may or may not be able to build Perl from source on such a platform.

But it’s not just about the operating system. When Perl was configured, did you turn on threads? 64 bit? longdouble or quadmath? Were you using the default C compiler, or gcc? MacOS built with all the default configuration options may be in the top tier, but with threads or quadmath may be in the 3rd tier.

Why is this useful?

End users might want to know how reliable Perl is on their platform. If they run `perl -v` and it tells them "this is a tier 2 configuration", then we can refer to a doc that explains what that means, and explains the implications in terms of potential reliability.

If a developer release fails a bunch of tests, these tiers help us know how much we should care, and how urgently we should fix the problem. This should help us prioritise.

This model should also let people know what they want to do if they want Perl to be more reliable on their platform. What’s needed to move Fuchsia from tier 4 to tier 3? And what about for tier 2? It will also give us a framework for talking about dropping support. Let’s say there a bunch of hairy code in the internals just for an old operating system, and removing it will make the code cleaner. For example, the hint file atheos.sh is for AtheOS. We can probably drop this, since the OS was discontinued and all support dropped years ago. If a platform is currently tier 1, how quickly should we be allowed to drop it down to 3?

What next?

First we need to agree on the general outline: how many levels are useful, without being too complicated for end users? We then need to agree on the definitions for each level, and once we’ve done that, do a first pass at assigning all known platforms/configurations to a level. We’ll probably argue back and forth on that, and in the process may increase or decrease the number of levels and/or tweak their definitions. And I think it would be helpful if perl -v could tell the user what tier their Perl is on.

Please shout if any of the above isn’t clear, and I’ll try to resolve that.

Neil

[1] https://github.com/Perl/perl5/tree/blead/hints
[2] https://docs.google.com/document/d/1RdBT0T6c61yYlOhtcgU9RFHB0pxXcnEhDsdW8hRteOc/edit?usp=sharing
[3] https://en.wikipedia.org/wiki/Google_Fuchsia
Re: "platforms" and "support" [ In reply to ]
2021-6-16 4:44 Neil Bowers <neilb@neilb.org> wrote:

>
> *Why is this useful?*
>
> End users might want to know how reliable Perl is on their platform. If
> they run `perl -v` and it tells them "this is a tier 2 configuration", then
> we can refer to a doc that explains what that means, and explains the
> implications in terms of potential reliability.
>


Thank you. I understand something this document achieves.

I understand something this document achieves.

End users can see that the Perl support level of your environment is Tier
1, 2, 3, or 4.



I have a suggestion here.

Is it possible to change the term "Tier" in an easy-to-understand term? For
example, "Support Level"

And is it possible to change the term "Battle Tested" in an
easy-to-understand term? For example, "Widely Tested"

I'm not English native. I don't know if that word is good.

The words "Tier" and "Battle Tested" are difficult to understand for me.
Re: "platforms" and "support" [ In reply to ]
On 6/15/21 3:44 PM, Neil Bowers wrote:
> Hi Kimoto-san,
>
> Can you tell me more details about this. I can't understand the
> meanings. tier is difficult word to understand for me.
>
>
> I’ll try and describe the problem, and what we want to do.
>
> Perl builds on many different operating systems (OSes). In the hints
> directory[1] you’ll find 82 hints files, for 70 different named OSes.
> Beyond a hints file, the OS may be checked with $^O in the testsuite,
> and there may be #ifdef’s in the C code. And maybe even an object file
> included in the Perl distribution!
>
> But not all of those platforms are equal. Linux is widely used, and we
> put a lot of effort into making sure it builds and passes all tests. But
> for some OSes we don’t even know whether 5.34.0 will build on it – some
> hints files were last edited years ago.
>
> *Tiers*
>
> We want to define a number of "levels" or "tiers" of support. I’ll
> describe one possibility below, based on what’s in the document I shared[2].
>
> The top tier is those platforms we’d consider "battled-tested", to
> borrow Curtis’s phrase: Linux, Windows, MacOS, and maybe one or two
> more? For these platforms we have reliable CI testing whenever something
> is committed to blead, and core developers have access to them. We
> consider Perl to be very reliable on these. We’d try and ensure good
> coverage on CPAN Testers as well, for example.
>

FreeBSD and OpenBSD must be considered top-tier. For example, perl is
so integral to OpenBSD that it is part of the "base" system, i.e., it is
not a port/package.

I would like to put NetBSD in the same category -- except that I/we
don't really *know* anyone we can reliably contact in the NetBSD project
to communicate with. This is sad, especially since, in a certain sense,
NetBSD is the "oldest" of the *BSDs. So NetBSD, for the time being,
would not qualify for tier 1. But we still do better there than on ...

DragonflyBSD I would not put in the top tier. We have only one person
sending smoke-test reports (Carlos, of course). I have not been able to
get a Dragonfly VM working.

Thank you very much.
Jim Keenan
Jim Keenan
Re: "platforms" and "support" [ In reply to ]
Applying Cunningham’s law, I’ve been through all the hints files, and allocated them to the four tiers[1], based on what I know. Which in many cases isn’t very much.

Where the OS was discontinued a decent number of years ago, and I’m not aware of an open source fork, I’ve put them in tier 4, which is a list for potential culling ("the Jarkko treatment", I’m told).

See what you think: https://docs.google.com/document/d/17DuECm3Rs9NWK15JBbJTpFgPxa2lgd9Y89NCtS-ThSk/edit?usp=sharing

Neil

[1] https://docs.google.com/document/d/1RdBT0T6c61yYlOhtcgU9RFHB0pxXcnEhDsdW8hRteOc/edit?usp=sharing
Re: "platforms" and "support" [ In reply to ]
On 6/16/21 5:52 PM, Neil Bowers wrote:
> Applying Cunningham’s law, I’ve been through all the hints files, and
> allocated them to the four tiers[1], based on what I know. Which in many
> cases isn’t very much.
>
> Where the OS was discontinued a decent number of years ago, and I’m not
> aware of an open source fork, I’ve put them in tier 4, which is a list
> for potential culling ("the Jarkko treatment", I’m told).
>
> See what you think:
> https://docs.google.com/document/d/17DuECm3Rs9NWK15JBbJTpFgPxa2lgd9Y89NCtS-ThSk/edit?usp=sharing
> <https://docs.google.com/document/d/17DuECm3Rs9NWK15JBbJTpFgPxa2lgd9Y89NCtS-ThSk/edit?usp=sharing>
>

LGTM
Re: "platforms" and "support" [ In reply to ]
On Wed, 16 Jun 2021 22:52:06 +0100
Neil Bowers <neilb@neilb.org> wrote:

> See what you think:?https://docs.google.com/document/d/17DuECm3Rs9NWK15JBbJTpFgPxa2lgd9Y89NCtS-ThSk/edit?usp=sharing

My problem with that list is that it doesn't address operating system
*versions*. Windows is listed as just "Windows", what does it mean for
e.g. Windows XP?

Anyway, here are my comments about some of the platforms:

>catamount.sh (Catamount is an OS for supercomputers)

Tier 4, no one is using legacy supercomputers.

>greenhills.sh - not sure if this refers to the Greenhills C compiler, or the Greenhills real-time operating system Integrity-178

Just like you, I have no idea what this hints file is for, so Tier 4.

>i386.sh ? is this for OpenBSD i386?

It isn't for OpenBSD and it's hard to tell what is was meant for,
probably some SCO unix. It should be removed.

Some context after digging through the git history: back in Perl4 days,
one of the ways how Configure was picking a hints file was using the
fifth field of `uname -a`, which on some platforms contains the
architecture (like i386):

https://github.com/Perl/perl5/blob/e334a159a5616cab575044bafaf68f75b7bb3a16/Configure#L785

It is still examining that field, but it isn't using it directly as a
filename component and it's limited to a few choices:

https://github.com/Perl/perl5/blob/f8058fd524d40ef43e9d826eb61b863b26f9e73f/Configure#L3422

>ncr_tower.sh - NCR Tower systems ran a variant of System V. I can't find much current stuff about this, so can it be dropped?

Tier 4.

>opus.sh ? Opus was a microkernel that followed on from the Pink operating system at Apple, which also led to TalOS.

After a bit of googling, I think that TalOS and Pink were never released
publicly, so it's *probably* for something else, but I have no idea what
it would be. Also, note that "mpc.sh" is identical and was added at the
same time. Both belong in Tier 4.

>stellar.sh - is this Stellar Mate OS?

No, StellarMate OS is a Linux distribution and it definitely wasn't
around in 1991. No idea what it is, so Tier 4.

>unicos.sh - UNICOS is a range of Unix-like operating systems for Cray supercomputers, now based on Linux.

Tier 4, no one is using legacy supercomputers.

>uwin.sh - it says this is for "Unix for Windows", but is this the hint file used for Windows? In which case it's tier 1!

UWIN was a competitor to Cygwin, the last release was in 2012 and it never
was popular to begin with. Tier 4 IMO (https://en.wikipedia.org/wiki/UWIN)
Re: "platforms" and "support" [ In reply to ]
2021-6-17 6:52 Neil Bowers <neilb@neilb.org> wrote:

>
> See what you think:
> https://docs.google.com/document/d/17DuECm3Rs9NWK15JBbJTpFgPxa2lgd9Y89NCtS-ThSk/edit?usp=sharing
>
>
>
I can't find Symbian OS in the list.
Re: "platforms" and "support" [ In reply to ]
2021-6-17 6:52 Neil Bowers <neilb@neilb.org> wrote:

>
> See what you think:
> https://docs.google.com/document/d/17DuECm3Rs9NWK15JBbJTpFgPxa2lgd9Y89NCtS-ThSk/edit?usp=sharing
>
>
>
The list doesn't contain msys2. In Perl, Is msys2 the same as cygwin?
Re: "platforms" and "support" [ In reply to ]
> My problem with that list is that it doesn't address operating system*versions*. Windows is listed as just "Windows", what does it mean fore.g. Windows XP?

This is a first pass to put operating systems into buckets, and particularly to identify ones that we can drop. Any we’re dropping, we don’t need to worry about versions.

Once that’s done, _then_ I figured we’d worry about OS versions, toolchain, longdouble & quadmath, threaded, etc.
Re: "platforms" and "support" [ In reply to ]
Yuki Kimoto <kimoto.yuki@gmail.com> writes:

> 2021-6-17 6:52 Neil Bowers <neilb@neilb.org> wrote:
>
>>
>> See what you think:
>> https://docs.google.com/document/d/17DuECm3Rs9NWK15JBbJTpFgPxa2lgd9Y89NCtS-ThSk/edit?usp=sharing
>>
> I can't find Symbian OS in the list.

That's because it was dropped in 5.34:
https://perldoc.perl.org/5.34.0/perldelta#Symbian

- ilmari
Re: "platforms" and "support" [ In reply to ]
On Sun, Jun 13, 2021 at 04:17:08PM +0100, Neil Bowers wrote:
> I wrote up some thoughts on this, which ended up in a Google doc so I could iterate with Nick and then Rik.


> You can see and comment on the document:
> https://docs.google.com/document/d/1RdBT0T6c61yYlOhtcgU9RFHB0pxXcnEhDsdW8hRteOc/edit?usp=sharing

[I have never found commenting in the margins of Google docs to be a useful way
to have a conversation, so I'm posting here instead.)

Under Tier 4, the phrase

We won't accept patches (unless we're expecting/want it to move up)

seems unnecessarily unfriendly. If a patch is simple and unobtrusive,
I'd hope we would accept it. If it's an invasive patch, of course, some
hesitancy before applying would certainly be appropriate. Also, if we
won't accept patches, then how can you get from new/unkown to known?
How do you find other users of a new platform who might want to build
perl? I'd hope perl itself could be that place.

More broadly, the issue of the complexity of support for a platform
should probably be relevant, and I fear it will make the whole business
of defined support tiers much more complicated.

--
Andy Dougherty doughera@lafayette.edu
Re: "platforms" and "support" [ In reply to ]
2021-6-17 20:22 Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>:

> Yuki Kimoto <kimoto.yuki@gmail.com> writes:
>
> > 2021-6-17 6:52 Neil Bowers <neilb@neilb.org> wrote:
> >
> >>
> >> See what you think:
> >>
> https://docs.google.com/document/d/17DuECm3Rs9NWK15JBbJTpFgPxa2lgd9Y89NCtS-ThSk/edit?usp=sharing
> >>
> > I can't find Symbian OS in the list.
>
> That's because it was dropped in 5.34:
> https://perldoc.perl.org/5.34.0/perldelta#Symbian
>
> - ilmari
>

Oh, I did not know from now. Thank you for PERL_GLOBAL_STRUCT cleanup!
Re: "platforms" and "support" [ In reply to ]
2021-6-17 22:31 Andy Dougherty <doughera@lafayette.edu> wrote:

> On Sun, Jun 13, 2021 at 04:17:08PM +0100, Neil Bowers wrote:
> > I wrote up some thoughts on this, which ended up in a Google doc so I
> could iterate with Nick and then Rik.
>
>
> > You can see and comment on the document:
> >
> https://docs.google.com/document/d/1RdBT0T6c61yYlOhtcgU9RFHB0pxXcnEhDsdW8hRteOc/edit?usp=sharing
>
> [I have never found commenting in the margins of Google docs to be a
> useful way
> to have a conversation, so I'm posting here instead.)
>
> Under Tier 4, the phrase
>
> We won't accept patches (unless we're expecting/want it to move up)
>
> seems unnecessarily unfriendly.
>
>
The maintainers are a small number of volunteers, so if they do
everything, they will burn out.

If you think you need more support, why not look for a Perl-friendly
sponsor?

For example, create a donation slot.
Re: "platforms" and "support" [ In reply to ]
On Thu, Jun 17, 2021 at 8:31 AM Andy Dougherty <doughera@lafayette.edu> wrote:
>
> On Sun, Jun 13, 2021 at 04:17:08PM +0100, Neil Bowers wrote:
> > I wrote up some thoughts on this, which ended up in a Google doc so I could iterate with Nick and then Rik.
>
>
> > You can see and comment on the document:
> > https://docs.google.com/document/d/1RdBT0T6c61yYlOhtcgU9RFHB0pxXcnEhDsdW8hRteOc/edit?usp=sharing
>
> [.I have never found commenting in the margins of Google docs to be a useful way
> to have a conversation, so I'm posting here instead.)

[Same here.]

I wonder whether folks have thought through the implications of
"Commits to blead are CI tested" for Tier 1. If CI means GitHub CI,
the implication is that GitHub chooses for us what platforms get to be
Tier 1, currently only a couple recent versions each of Linux (Ubuntu
only apparently), Windows, and macOS.[1] If this narrow restriction
for Tier 1 is intentional, perhaps we should be more explicit about
it.

In theory, one can have a CI runner on an OS that is not provided by
GitHub, but to do it you have to use the runner application from
<https://github.com/actions/runner>. That is a C# / .NET Core
application, which as far as I know doesn't really get you any more
platforms than the GitHub-hosted runners except for some non-Ubuntu
Linux variants plus possibly older versions of the supported
platforms.[2]

These observations are based on reading the GitHub docs, not on
experience, so people who know better should correct me if I've got
this wrong.

If automated test reports generated by Test::Smoke count as CI, then
you can ignore what I said in the preceding paragraphs. But then CI
seems like the wrong thing to call it since we would then have
continuous integration without the integration part.

[1] <https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners>

[2] There does appear to be a FreeBSD port of .NET Core:
<https://github.com/jasonpugsley/installer/wiki/.Net-Core-3.0.0-for-FreeBSD>.
I have no idea whether it's adequate for the runner application
mentioned above, or whether it's likely to stay adequate reliably.
Re: "platforms" and "support" [ In reply to ]
On Fri, Jun 18, 2021 at 09:55:45AM +0900, Yuki Kimoto wrote:
> 2021-6-17 22:31 Andy Dougherty <doughera@lafayette.edu> wrote:

> > Under Tier 4, the phrase
> >
> > We won't accept patches (unless we're expecting/want it to move up)
> >
> > seems unnecessarily unfriendly.
> >
> >
> The maintainers are a small number of volunteers, so if they do
> everything, they will burn out.

Yes, I am certainly familiar with that problem, but I don't think
that's of central importance in this context.

> If you think you need more support, why not look for a Perl-friendly
> sponsor?
>
> For example, create a donation slot.

I appreciate you trying to trim unnecessary content, but in this case,
I think you trimmed so much that the original context is lost. The very
next sentence was:

> > If a patch is simple and unobtrusive, I'd hope we would accept it.

That is, I am envisioning a situation where a user has a patch (or
patches) they want to contribute to perl to support a new platform.
The user is not asking p5p volunteerrs to come up with the patch or
provide support, but simply accept an offered patch.

Yes, it is work to evaluate such a patch, but if we simply categorically
reject all new platforms, then how can any new system move from new/unknown
to known? How does a new user bootstrap the process? How do you get enough
other interested users to convince p5p that "we're expecting/want it to move up"?
Or, as I wrote in my original message:

> > How do you find other users of a new platform who might want to build
> > perl? I'd hope perl itself could be that place.

I have no argument with the ideas that substantial complex patches need
to be evaluated thoughtfully, that such review is work, and that not
all such patches are appropriate. I just think that the draft wording
is not welcoming, and out of step with Perl's traditional aspirations
of portability.

--
Andy Dougherty doughera@lafayette.edu
Re: "platforms" and "support" [ In reply to ]
> Under Tier 4, the phrase
> We won't accept patches (unless we're expecting/want it to move up)
> seems unnecessarily unfriendly. If a patch is simple and unobtrusive,I'd hope we would accept it. If it's an invasive patch, of course, somehesitancy before applying would certainly be appropriate.

How about something like:

    We won’t accept complex / intrusive patches unless we’re expecting/want it to move up to tier 3.
    Minor platform-specific patches may be accepted, but doing so will move the platform up to tier 3, by definition.

1 2  View All