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

Re: "platforms" and "support"

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
May 28, 2021 08:12
Subject:
Re: "platforms" and "support"
Message ID:
20210528081210.GL16931@etla.org
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

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