Mailing List Archive

PSC #025 2021-06-18 minutes
Here are the (delayed) minutes from 9 days ago. Again, I prioritised my
finite time hustling RFCs and other things over getting minutes done.


Neil, Nick and Rick present.

## Help wanted testing try/catch

We briefly discussed how we can make it easier for more people to "help with
the heavy lifting" as a general model. A good example was the new try/catch
feature. A lot of people seem keen to have this, but if everyone assumes
that someone else is going to test it, then bugs will lurk, and we'll never
get it "out of experimental". Paul wrote more at
https://www.nntp.perl.org/group/perl.perl5.porters/2021/06/msg260462.html

The bottom line is "your language needs you!" - please "try" this out in
real code so that we can "catch" the bugs.

(The bad puns will continue until the testing improves...)

## Actions from last time

Most had been done. Rik has now posted the gory details of ternaries and the
AASIGN/SASSIGN ops, and thoughts on pragmata, features, and version bundles.
Nick *still* hasn't written up a list of obscure corner cases to test with.

## RFCs

We considered the outstanding issues for n-at-a-time for, resolved them, and
agreed that the RFC moves to the "accepted" state. This means that "we think
this plan looks viable" and it's ready to implement. It is now implemented,
and awaiting review as https://github.com/Perl/perl5/pull/18925

Specifically, we asked "does this need a feature gate?" and "does this need
an experimental warning?" Existing precedents on this:

* ~~ is not feature gated, but is warning as experimental pair slicing was
* neither gated nor warned - Rik says: I was sure it was the correct design,
and the only question was bugs; experimental warnings and feature gates
aren't about bugs.
* It seems that for these we're wanting warnings as "might be buggy", but
heck, *anything* we change might be buggy, so we're not unanimously keen
on singling out the *implementation* of simple new features as special
here. warnings discourage people from using it and shaking out bugs -
long term we need the bugs gone
* For example, try/catch lurked for a while, and it seems that no-one really
tested it
* Being able to retroactively disable experimental warnings might help here
[*] - if we can deliver on this, then we'd have fewer reservations about
initially shipping with warnings

We considered warning on -w -np and agreed that the RFC was "rejected"

* How much value is this going to add, and for whom?
* We are discouraging the use of -w (ie we recommend `use warnings;`), so
why are we gating this warning on -w? (Because, obviously, for CLI flag
warnings there's no choice)
* Does the change the warning would recommend remove some surprise? No, not
really.
* Instead it takes code that works and suggests more work.

We discussed some questions about process, but didn't come to firm
answers. Such as

* "If we get to 100 approved RFCs, could we actually say what the future of
perl is?" given that we can't know when/whether any individual RFC will
get implemented.
* Will we get overwhelmed if too many RFCs arrive for discussion at the same
time?
* Can we avoid worrying about formal limits on RFCs in each state (prior to
approved) - we hope that there will be natural rate limiting

We are strongly of the opinion that the first step is not a draft RFC, but a
much shorter "elevator pitch". We quickly settled on a "four paragraph"
e-mail:

1. Here's the problem that I want to solve
2. Here's the syntax that I'm proposing
3. Here are the benefits
4. Here are potential problems

If a paragraph is just one sentence, that's great.

What we want to avoid is people diligently using the template, but as a
result creating verbose "form letters" which are long enough that most
people skip reading them, and hence the intended rapid feedback doesn't
happen.

What we want is a rapid answer to "is there any appetite for discussing
this?" and if there isn't a "no" then you draft an RFC. (At the time, we
considered whether "even silence" is not-a-"no". Since then, Nick now has a
slightly more detailed suggestion for the current PSC to consider)

If we get rapid yes/more info/CPAN/no feedback within 48 hours, we think
that we won't need any formal documented to track the state of "pre-RFCs"

We intended to trial this with Rik submitting an "elevator pitch" for
everything slices.

## 5.34.1

We discussed the GDBM_File performance issue in
https://github.com/Perl/perl5/issues/18884

As it's caused by the external library, not perl code, it was a coincidence
that was discovered by 5.34.0, and hence it's not an issue for 5.34.1

However, since the meeting it seems that the fix for the bug in the current
gdbm library (version 1.20) requires a change in the GDBM_File XS code, so
potentially there is a 5.34.1 backport needed. See
https://github.com/Perl/perl5/issues/18915

We discussed how the .N (>0) releases work. We need to be careful with maint
releases - they are *somewhat like* dev releases, but far more dangerous.

The current process predates our migration to GitHub, and started with a web
frontend that wrote out an XML file to track "backport votes", and share the
work of deciding what was necessary and safe to backport. We wondered
whether we can make anything simpler by finding features of GitHub that
could help, but we failed to assign an "action item" to any one individual,
so, whoops, it has stalled.

## Indexing permissions on core modules

Neil noticed that the PAUSE permissions on Text::Tabs and Text::Wrap seemed
a bit strange, given that the modules are shipped as dual life in core, and
hence potentially might need critical fixes. Neil was going to contact the
author to find a resolution, and also check all the other upstream blead
code to see that the PAUSE permissions made sense.

## Quirks

Neil has been working on a document collating many Perl features that are
often viewed as misfeatures. The intent is to have a common baseline for
discussing what we think are oddities of the language, so that we start from
the same place when discussing what some "emergent behaviour" or similar is,
why it ended up how it is today, and whether we want to do anything about it
(or even can - maybe the costs of changing it are too high). This is nearly
ready to go public. (Hardware issues have knocked Neil mostly offline for
the past week, hence it hasn't been finished.)

## Minimum perl versions (and encouraging adoption of our new features)

We discussed how it's frustrating that each year we ship a new version of
Perl, but the take up of the improvements is limited because folks shipping
code to CPAN are reluctant to use them because they favour supporting the
long tail of older versions. At some level, this conflict of incentives
actually makes it arguably pointless to try to add features/fix the
deficiencies of the language, which isn't what we want.

The rough conclusion was that the trade offs that the toolchain authors
choose is sensible for the toolchain, but we don't think that other modules
should adopt the toolchain end conclusion *unthinkingly*.

## Supported Platforms

Neil had made good progress in collating feedback on "supported platforms",
and was close to having a coherent document to propose. The overview is that
we have 4 tiers, currently described as

1. Battle tested
2. Stable
3. Unmaintained
4. Unknown

To be in tier 1, a platform needs to provide reliable Continuous
Integration, so that we get test results promptly for changes made to
blead. GitHub doesn't offer CI for FreeBSD and OpenBSD, but we'd like to
make these tier 1, so we need to approach them to ask if they have resources
we can use.

We also noted that our list of current platforms is based on hints files and
similar. We have hints files for platforms that have been dead for over 10
years - these are in our "tier 4 list" and we propose to remove these.
However, we don't (yet) have a table of $^O values for platforms that we
have already removed. For example, BeOS is long gone, but there are still
some tests that check for $^O matching 'BeOS'. This could usefully go.

So we also need to collate the "known dead" values of $^O, so that anyone
working on the code base can easily confirm that special-case code is dead
and can be removed.

## Data-Dumper issue queue

Data::Dumper is "upstream blead". Unlike several other modules with the same
state, its code is not mirrored into a specific repository, and hence no
repository exists for a ticket queue. As a result, we intend to change the
distribution META.json to point bug reports to the main perl issue queue, as
that is where the code is. Hence the existing (default) rt.cpan.org queue is
no longer active. There are currently about 30 issues in there. Jim Keenan
has already reviewed the tickets, but is keen to avoid importing tickets
which could be solved instead:
https://github.com/Perl/perl5/pull/18832#issuecomment-860210283

He's asked for help - some bugs might need fixes in Dumper.xs

PSC is keen for this to happen - volunteer(s) needed, but also to avoid the
process stalling and hence never completing. So we're suggesting a timebox -
do as much as possible by 31st August 2021, and then import every ticket
that hasn't been fixed by then.

## postderef_qq

Hugo asked for some clarification on this. Rik was to follow up with a
specific answer to Hugo (and has done so). Nick was to follow up with
starting to document Perl's general design principles, which are being
mentioned piecemeal or in passing as we discuss various RFCs. Nick has not
done this yet.

## Security fuzzing and typeglob assignment

Nick noted that typeglob assignment bugs feature disproportionately highly
in the security bugs we get reported, compared with how often they are used
in production code. This seems to be because the short syntax for typeglobs
makes them likely to get hit by fuzzers. The bugs *are* legitimate, but we
(and the researchers reporting them) then have to spend time investigating
them, usually to find that they are due to the stack not reference counted,
and could only be exploited if you can already inject code (in which case,
it's already game over), so they are not in need of a security fix. Nick was
wondering about ways to systematically fix at least some of these bugs, but
hasn't had time to go further on this yet. (RFCs took priority)

## Footnote - "retroactively disable experimental warnings"

When discussing the stability of experimental features, Rik has often noted
that the first perl version that offered lexical subroutines had an
implementation with serious bugs, such that you shouldn't use it. But a
later release (v5.22.0) fixed these, and as nothing changed for two
releases, it's no longer considered as experimental, and doesn't warn. But
with hindsight we can say you *can* safely use lexical subs in v5.22.0 or
later, despite the warning, because we now know that it's good. (The warning
went away in v5.26.0.)

Hence at times we've wondered whether we could implement some way to
formalise this - split out some part of the implementation of the warnings
pragma, such that

your code to ask to disable warnings for proven successful experiments we
could upload updates about "success" to CPAN as a dual life module

That way, we'd get a two year "head start" on the widespread use of new
features. At the point when experiments end, you could count on at least
some distributions having already shipped a perl "new" enough to use them
safely.

We'd not minuted this previously because we didn't have a firmer plan, or
any need to reference what is a thought experiment. We do now.
Re: PSC #025 2021-06-18 minutes [ In reply to ]
On Sun, Jun 27, 2021 at 5:55 AM Nicholas Clark <nick@ccl4.org> wrote:

> ## Minimum perl versions (and encouraging adoption of our new features)
>
> We discussed how it's frustrating that each year we ship a new version of
> Perl, but the take up of the improvements is limited because folks shipping
> code to CPAN are reluctant to use them because they favour supporting the
> long tail of older versions. At some level, this conflict of incentives
> actually makes it arguably pointless to try to add features/fix the
> deficiencies of the language, which isn't what we want.
>
> The rough conclusion was that the trade offs that the toolchain authors
> choose is sensible for the toolchain, but we don't think that other modules
> should adopt the toolchain end conclusion *unthinkingly*.
>

I'm not really sure what PSC can do about this, other than make
recommendations. CPAN authors will choose the minimum that they feel is
worth supporting and users will require the minimum they need.


> ## Footnote - "retroactively disable experimental warnings"
>
> When discussing the stability of experimental features, Rik has often noted
> that the first perl version that offered lexical subroutines had an
> implementation with serious bugs, such that you shouldn't use it. But a
> later release (v5.22.0) fixed these, and as nothing changed for two
> releases, it's no longer considered as experimental, and doesn't warn. But
> with hindsight we can say you *can* safely use lexical subs in v5.22.0 or
> later, despite the warning, because we now know that it's good. (The
> warning
> went away in v5.26.0.)
>
> Hence at times we've wondered whether we could implement some way to
> formalise this - split out some part of the implementation of the warnings
> pragma, such that
>
> your code to ask to disable warnings for proven successful experiments we
> could upload updates about "success" to CPAN as a dual life module
>
> That way, we'd get a two year "head start" on the widespread use of new
> features. At the point when experiments end, you could count on at least
> some distributions having already shipped a perl "new" enough to use them
> safely.
>
> We'd not minuted this previously because we didn't have a firmer plan, or
> any need to reference what is a thought experiment. We do now.
>

experimental.pm is dual life, and often a recommended way to use
experimental features. Perhaps this can be leveraged as such a mechanism?

-Dan
Re: PSC #025 2021-06-18 minutes [ In reply to ]
On Sun, 27 Jun 2021 09:55:24 +0000
Nicholas Clark <nick@ccl4.org> wrote:

> ## Minimum perl versions (and encouraging adoption of our new
> features)
>
> We discussed how it's frustrating that each year we ship a new
> version of Perl, but the take up of the improvements is limited
> because folks shipping code to CPAN are reluctant to use them because
> they favour supporting the long tail of older versions. At some
> level, this conflict of incentives actually makes it arguably
> pointless to try to add features/fix the deficiencies of the
> language, which isn't what we want.

Frustrating, indeed.

My personal thoughts on this for my own code are:

New modules: perl >= 5.26. That version chosen because it added
enough core ops to allow `Object::Pad` to support signatures on
methods. Combined with Future::AsyncAwait this combo enables some
seriously nice powerful code like

has $_read_f;

async method read_idx ($idx) {
return (await $_read_f //= $self->_read_rgb)[$idx];
}

Existing modules: perl >= 5.16, for the most part. A few exceptions
exist for really high-river ones (e.g. List::Util, IO::Socket::IP)
but for most of these, taking 5.16 onwards means at least basic
support of try/catch, async/await, Object::Pad via syntax modules,
even though the signatures aren't yet available.

I have so far not yet encountered a case where anyone cared about a
perl older than 5.16.


> ## Footnote - "retroactively disable experimental warnings"
...

Yes - I like the sound of this.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: PSC #025 2021-06-18 minutes [ In reply to ]
On 2021-06-27 3:31 p.m., Paul "LeoNerd" Evans wrote:
> Existing modules: perl >= 5.16, for the most part. A few exceptions
> exist for really high-river ones (e.g. List::Util, IO::Socket::IP)
> but for most of these, taking 5.16 onwards means at least basic
> support of try/catch, async/await, Object::Pad via syntax modules,
> even though the signatures aren't yet available.
>
> I have so far not yet encountered a case where anyone cared about a
> perl older than 5.16.

DBI still cares about Perl from 5.8.1 and up; I recently asked and there are no
plans to change this.

Similarly, DBI wrappers like DBIx::Class also care about Perl 5.8.1.

For my part, I plan to release brand new modules in that space, and on one hand
since they're brand new I was thinking of just defaulting to the latest Perl
version at the time eg 5.34 and then ratchet it down if people explicitly ask
for that.

On the other hand the oldest I would ever want to support is the same version
that DBI itself does BECAUSE DBI itself does, and in theory any features I need
from Perl were present in 5.8.1 and its just syntactic niceties that came
afterwards. Except I would round to 5.8.0 because 1 seems arbitrary in my case.

-- Darren Duncan
Re: PSC #025 2021-06-18 minutes [ In reply to ]
On Sun, Jun 27, 2021 at 6:45 PM Darren Duncan <darren@darrenduncan.net>
wrote:

> On 2021-06-27 3:31 p.m., Paul "LeoNerd" Evans wrote:
> > Existing modules: perl >= 5.16, for the most part. A few exceptions
> > exist for really high-river ones (e.g. List::Util, IO::Socket::IP)
> > but for most of these, taking 5.16 onwards means at least basic
> > support of try/catch, async/await, Object::Pad via syntax modules,
> > even though the signatures aren't yet available.
> >
> > I have so far not yet encountered a case where anyone cared about a
> > perl older than 5.16.
>
> DBI still cares about Perl from 5.8.1 and up; I recently asked and there
> are no
> plans to change this.
>
> Similarly, DBI wrappers like DBIx::Class also care about Perl 5.8.1.
>
> For my part, I plan to release brand new modules in that space, and on one
> hand
> since they're brand new I was thinking of just defaulting to the latest
> Perl
> version at the time eg 5.34 and then ratchet it down if people explicitly
> ask
> for that.
>
> On the other hand the oldest I would ever want to support is the same
> version
> that DBI itself does BECAUSE DBI itself does, and in theory any features I
> need
> from Perl were present in 5.8.1 and its just syntactic niceties that came
> afterwards. Except I would round to 5.8.0 because 1 seems arbitrary in my
> case.
>

In this case (and similarly for 5.10.0) the 1 is unfortunately not
arbitrary; 5.8.0 is horribly broken, and luckily did not find widespread
usage.

-Dan
Re: PSC #025 2021-06-18 minutes [ In reply to ]
??????? Original Message ???????
On Sunday, June 27th, 2021 at 12:08 PM, Dan Book <grinnz@gmail.com> wrote:

> On Sun, Jun 27, 2021 at 5:55 AM Nicholas Clark <nick@ccl4.org> wrote:
>
>> ## Minimum perl versions (and encouraging adoption of our new features)
>>
>> We discussed how it's frustrating that each year we ship a new version of
>> Perl, but the take up of the improvements is limited because folks shipping
>> code to CPAN are reluctant to use them because they favour supporting the
>> long tail of older versions. At some level, this conflict of incentives
>> actually makes it arguably pointless to try to add features/fix the
>> deficiencies of the language, which isn't what we want.
>>
>> The rough conclusion was that the trade offs that the toolchain authors
>> choose is sensible for the toolchain, but we don't think that other modules
>> should adopt the toolchain end conclusion *unthinkingly*.
>
> I'm not really sure what PSC can do about this, other than make recommendations. CPAN authors will choose the minimum that they feel is worth supporting and users will require the minimum they need.
>
>> ## Footnote - "retroactively disable experimental warnings"
>>
>> When discussing the stability of experimental features, Rik has often noted
>> that the first perl version that offered lexical subroutines had an
>> implementation with serious bugs, such that you shouldn't use it. But a
>> later release (v5.22.0) fixed these, and as nothing changed for two
>> releases, it's no longer considered as experimental, and doesn't warn. But
>> with hindsight we can say you *can* safely use lexical subs in v5.22.0 or
>> later, despite the warning, because we now know that it's good. (The warning
>> went away in v5.26.0.)
>>
>> Hence at times we've wondered whether we could implement some way to
>> formalise this - split out some part of the implementation of the warnings
>> pragma, such that
>>
>> your code to ask to disable warnings for proven successful experiments we
>> could upload updates about "success" to CPAN as a dual life module
>>
>> That way, we'd get a two year "head start" on the widespread use of new
>> features. At the point when experiments end, you could count on at least
>> some distributions having already shipped a perl "new" enough to use them
>> safely.
>>
>> We'd not minuted this previously because we didn't have a firmer plan, or
>> any need to reference what is a thought experiment. We do now.
>
> experimental.pm is dual life, and often a recommended way to use experimental features. Perhaps this can be leveraged as such a mechanism?
>
> -Dan

FWIW, I was watching this year-old video on ZFS, and Allan Jude covers some aspect of how the OpenZFS project is managed (from the perspective of FreeBSD).

In particularly, the concept of "feature flags" seems somewhat applicable to perl. I am not saying it's directly applicable, the challenges are different. However, this model is similar enough that it might provide some further refinements to how perl handles features, experiements, etc.

Some background on ZFS feature flags:

* https://web.archive.org/web/20160419064650/http://blog.delphix.com/csiden/files/2012/01/ZFS_Feature_Flags.pdf
* https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Feature%20Flags.html

Cheers,
Brett
Re: PSC #025 2021-06-18 minutes [ In reply to ]
On 2021-06-27 5:47 p.m., Dan Book wrote:
> On Sun, Jun 27, 2021 at 6:45 PM Darren Duncan wrote:
> On the other hand the oldest I would ever want to support is the same version
> that DBI itself does BECAUSE DBI itself does, and in theory any features I need
> from Perl were present in 5.8.1 and its just syntactic niceties that came
> afterwards.  Except I would round to 5.8.0 because 1 seems arbitrary in my case.
>
> In this case (and similarly for 5.10.0) the 1 is unfortunately not arbitrary;
> 5.8.0 is horribly broken, and luckily did not find widespread usage.

I had long assumed that the move to the Unicode character database 4.0 from 3.2
was the only major change of Perl 5.8.1 and since my module isn't sensitive to
that then 5.8.1 and 5.8.0 were essentially interchangeable, while others
requiring 5.8.1 were doing so mainly for that Unicode change.

Your comment now makes me think differently about this however.

But I still don't see a downside to just require 5.8.0 if I would otherwise
require 5.8.1 for simplicity. If 5.8.0 is so bad then people just wouldn't use
it apart from my own decision anyway.

-- Darren Duncan
Re: PSC #025 2021-06-18 minutes [ In reply to ]
On Mon, Jun 28, 2021 at 12:32 AM Paul "LeoNerd" Evans <
leonerd@leonerd.org.uk> wrote:

> Existing modules: perl >= 5.16, for the most part. A few exceptions
> exist for really high-river ones (e.g. List::Util, IO::Socket::IP)
> but for most of these, taking 5.16 onwards means at least basic
> support of try/catch, async/await, Object::Pad via syntax modules,
> even though the signatures aren't yet available.
>
> I have so far not yet encountered a case where anyone cared about a
> perl older than 5.16.
>

About 1 in 6 users of cpanm is using 5.16 (which generally means RHEL7),
any dist dropping that would affect a serious number of users. It is a
de-facto watershed.

Leon
Re: PSC #025 2021-06-18 minutes [ In reply to ]
On Sat, 3 Jul 2021 22:15:54 +0200
Leon Timmermans <fawaka@gmail.com> wrote:

> On Mon, Jun 28, 2021 at 12:32 AM Paul "LeoNerd" Evans <
> leonerd@leonerd.org.uk> wrote:
>
> > Existing modules: perl >= 5.16, for the most part. A few
> > exceptions exist for really high-river ones (e.g. List::Util,
> > IO::Socket::IP) but for most of these, taking 5.16 onwards means at
> > least basic support of try/catch, async/await, Object::Pad via
> > syntax modules, even though the signatures aren't yet available.
> >
> > I have so far not yet encountered a case where anyone cared about
> > a perl older than 5.16.
> >
>
> About 1 in 6 users of cpanm is using 5.16 (which generally means
> RHEL7), any dist dropping that would affect a serious number of
> users. It is a de-facto watershed.

Ah - a useful data point.

Can we presume from your response that there is a "negligible" long
tail older than 5.16 then? Do you have some more detailed breakdown
somewhere we can see?

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: PSC #025 2021-06-18 minutes [ In reply to ]
On Sat, Jul 3, 2021 at 10:42 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Sat, 3 Jul 2021 22:15:54 +0200
> Leon Timmermans <fawaka@gmail.com> wrote:
>
> > On Mon, Jun 28, 2021 at 12:32 AM Paul "LeoNerd" Evans <
> > leonerd@leonerd.org.uk> wrote:
> >
> > > Existing modules: perl >= 5.16, for the most part. A few
> > > exceptions exist for really high-river ones (e.g. List::Util,
> > > IO::Socket::IP) but for most of these, taking 5.16 onwards means at
> > > least basic support of try/catch, async/await, Object::Pad via
> > > syntax modules, even though the signatures aren't yet available.
> > >
> > > I have so far not yet encountered a case where anyone cared about
> > > a perl older than 5.16.
> > >
> >
> > About 1 in 6 users of cpanm is using 5.16 (which generally means
> > RHEL7), any dist dropping that would affect a serious number of
> > users. It is a de-facto watershed.
>
> Ah - a useful data point.
>
> Can we presume from your response that there is a "negligible" long
> tail older than 5.16 then? Do you have some more detailed breakdown
> somewhere we can see?
>

http://cpanmetadb.plackperl.org/versions/

Results tend to fluctuate somewhat (the statistics are daily) but are
mostly stable. 5.8 about 0.5%. 5.10 is about 2%, 5.12 is nonexistent. 5.14
is ±1%

Except for very recent versions the common versions are entirely dominated
by the major distributions .
5.30.0: Ubuntu 20.04 LTS
5.16.3: RHEL7
5.32.1: Ubuntu 21.04 and Debian testing/stretch
5.28.1: Debian stable
5.26.1: Ubuntu 18.04 LTS
5.26.3: RHEL 8
5.24.1: Debian oldstable
5.22.1: Ubultu 16.04 LTS
5.10.1: RHEL6

Leon
Re: PSC #025 2021-06-18 minutes [ In reply to ]
??, 27 ???. 2021 ?. ? 12:55, Nicholas Clark <nick@ccl4.org>:
> We discussed how the .N (>0) releases work. We need to be careful with maint
> releases - they are *somewhat like* dev releases, but far more dangerous.
>
> The current process predates our migration to GitHub, and started with a web
> frontend that wrote out an XML file to track "backport votes", and share the
> work of deciding what was necessary and safe to backport. We wondered
> whether we can make anything simpler by finding features of GitHub that
> could help, but we failed to assign an "action item" to any one individual,
> so, whoops, it has stalled.

I find the scale of this issue underappreciated. In past years, I've
asked for a number of fixes to be added to maint releases - and it
only worked since I've been around p5p for some time. Chances that any
particular eligible fix lands in maint are very slim, either it's
author should know the process or someone should notice it and push
the issue. Even than, it's far from guaranteed - I remember a commit
fixing Coro compilation breakage missing two 5.22 point releases until
it finally landed there, despite extensive discussion on this list.

It'd be great if PSC could provide a more robust and less error prone
process for this.

Best regards,
Sergey Aleynikov
Re: PSC #025 2021-06-18 minutes [ In reply to ]
On Sun, 4 Jul 2021 22:22:10 +0200, Leon Timmermans <fawaka@gmail.com>
wrote:

> On Sat, Jul 3, 2021 at 10:42 PM Paul "LeoNerd" Evans
> <leonerd@leonerd.org.uk> wrote:
>
> > On Sat, 3 Jul 2021 22:15:54 +0200
> > Leon Timmermans <fawaka@gmail.com> wrote:
> >
> > > On Mon, Jun 28, 2021 at 12:32 AM Paul "LeoNerd" Evans <
> [...]
> > >
> [...]
> > >
> > > About 1 in 6 users of cpanm is using 5.16 (which generally means
> > > RHEL7), any dist dropping that would affect a serious number of
> > > users. It is a de-facto watershed.
> >
> > Ah - a useful data point.
> >
> > Can we presume from your response that there is a "negligible" long
> > tail older than 5.16 then? Do you have some more detailed breakdown
> > somewhere we can see?
> >
>
> http://cpanmetadb.plackperl.org/versions/
>
> Results tend to fluctuate somewhat (the statistics are daily) but are
> mostly stable. 5.8 about 0.5%. 5.10 is about 2%, 5.12 is nonexistent.
> 5.14 is ±1%
>
> Except for very recent versions the common versions are entirely
> dominated by the major distributions .
> 5.30.0: Ubuntu 20.04 LTS
> 5.16.3: RHEL7
> 5.32.1: Ubuntu 21.04 and Debian testing/stretch
> 5.28.1: Debian stable
> 5.26.1: Ubuntu 18.04 LTS
> 5.26.3: RHEL 8
> 5.24.1: Debian oldstable
> 5.22.1: Ubultu 16.04 LTS
> 5.10.1: RHEL6
>
> Leon

An excerpt from
https://github.com/Tux/System-Info/blob/master/sandbox/dist-perl.csv

centos ? 8.4.2105 ? 2021-06-03 ? 5.30.1
centos ? 7.8.2003 ? 2020-04-27 ? 5.16.3
centos ? 6.10 ? 2018-07-03 ? 5.10.1
centos ? 5.11 ? 2014-09-30 ? 5.8.8
centos ? 4.8 ? 2009-08-22 ? 5.8.5
centos ? 3.9 ? 2007-07-27 ? 5.8.0
centos ? 2.0 ? 2004-05-24 ? 5.6.1
debian ? unstablesid ? 2021-06-22 ? 5.32.1
debian ? testingbullseye ? 2021-06-22 ? 5.32.1
debian ? 10buster ? 2019-07-06 ? 5.28.1
debian ? 9stretch ? 2017-06-18 ? 5.24.1
debian ? 8.0jessie ? 2015-04-26 ? 5.20.2
debian ? 7.0wheezy ? 2013-05-04 ? 5.14.2
debian ? 6.0squeeze ? 2011-02-06 ? 5.10.1
debian ? 5.0lenny ? 2009-02-15 ? 5.10.0
debian ? 4.0etch ? 2007-04-08 ? 5.8.8
debian ? 3.1sarge ? 2005-06-06 ? 5.8.4
debian ? 3.0woody ? 2002-07-19 ? 5.6.1
debian ? 2.2potato ? 2000-08-15 ? 5.4.5
debian ? 2.1slink ? 1999-03-09 ? 5.4.4
debian ? 2.0hamm ? 1998-07-23 ? 5.4.4
debian ? 1.3bo ? 1997-06-05 ? 5.3.7
debian ? 1.2rex ? 1996-12-12 ? 5.3.7
debian ? 1.1buzz ? 1996-06-17 ? 5.2
opensuse ? tumbleweed ? 2021-06-21 ? 5.32.1
opensuse ? 15.3 ? 2021-06-02 ? 5.26.1
opensuse ? 15 ? 2018-05-25 ? 5.26.1
opensuse ? 42.3 ? 2017-07-26 ? 5.18.2
opensuse ? 42.2 ? 2016-11-16 ? 5.18.2
opensuse ? 42.1 ? 2015-11-04 ? 5.18.2
opensuse ? 13.2 ? 2014-11-04 ? 5.20.1
opensuse ? 13.1 ? 2013-11-19 ? 5.18.1
opensuse ? 12.3 ? 2013-03-13 ? 5.16.2
opensuse ? 12.2 ? 2012-09-05 ? 5.16.0
opensuse ? 12.1 ? 2011-11-16 ? 5.14.2
opensuse ? 11.4 ? 2011-03-10 ? 5.12.3
opensuse ? 11.3 ? 2010-07-15 ? 5.12.1
opensuse ? 11.2 ? 2009-11-12 ? 5.10.0
opensuse ? 11.1 ? 2008-12-18 ? 5.10.0
opensuse ? 11.0 ? 2008-06-19 ? 5.10.0
opensuse ? 10.3 ? 2007-10-04 ? 5.8.8
opensuse ? 10.2 ? 2006-12-07 ? 5.8.8
opensuse ? 10.1 ? 2006-05-11 ? 5.8.8
opensuse ? 10.0 ? 2005-10-06 ? 5.8.7
opensuse ? 9.3 ? 2005-04-15 ? 5.8.6
opensuse ? 9.2 ? 2004-10-25 ? 5.8.5
opensuse ? 9.1 ? 2004-04-23 ? 5.8.3
opensuse ? 9.0 ? 2003-10-15 ? 5.8.1
opensuse ? 8.2 ? 2003-04-07 ? 5.8.0
opensuse ? 8.1 ? 2002-09-30 ? 5.8.0
opensuse ? 8.0 ? 2002-04-22 ? 5.6.1
opensuse ? 7.3 ? 2001-10-13 ? 5.6.1
opensuse ? 7.2 ? 2001-06-15 ? 5.6.0
opensuse ? 7.1 ? 2001-01-24 ? 5.6.0
opensuse ? 7.0 ? 2000-09-27 ? 5.5.3
opensuse ? 6.4 ? 2000-03-09 ? 5.5.3
opensuse ? 6.3 ? 1999-11-05 ? 5.5.3
opensuse ? 6.2 ? 1999-08-12 ? 5.5.3
opensuse ? 6.1 ? 1999-04-07 ? 5.5.2
opensuse ? 6.0 ? 1998-12-21 ? 5.5.2
opensuse ? 5.3 ? 1998-09-10 ? 5.4.4
opensuse ? 5.2 ? 1998-03-23 ? 5.4.4
redhat ? RHEL-8.4 ? 2021-05-21 ? 5.24.4
redhat ? RHEL-7.9 ? 2020-09-18 ? 5.16.3
redhat ? RHEL-6.9 ? 2017-03-21 ? 5.10.1
redhat ? RHEL-5.11 ? 2014-09-16 ? 5.8.8
redhat ? RHEL-4.8 ? 2009-05-19 ? 5.8.5
redhat ? RHEL-3.9 ? 2007-05-30 ? 5.8.0
redhat ? RHEL-2.1 ? 2002-03-26 ? 5.6.0
ubuntu ? snapshotimpish ? 2021-06-21 ? 5.32.1
ubuntu ? 21.04hirsute ? 2021-04-22 ? 5.32.1
ubuntu ? 20.10groovy ? 2020-10-22 ? 5.30.3
ubuntu ? 20.04 LTSfocal ? 2020-04-23 ? 5.30.0
ubuntu ? 19.10eoan ? 2019-10-17 ? 5.28.1
ubuntu ? 19.04disco ? 2019-04-18 ? 5.28.1
ubuntu ? 18.10cosmic ? 2018-10-18 ? 5.26.2
ubuntu ? 18.04 LTSbionic ? 2018-04-26 ? 5.26.1
ubuntu ? 17.10artful ? 2017-10-19 ? 5.26.0
ubuntu ? 17.04zesty ? 2017-04-13 ? 5.24.1
ubuntu ? 16.10yakkety ? 2016-10-13 ? 5.22.2
ubuntu ? 16.04 LTSxenial ? 2016-04-21 ? 5.22.1
ubuntu ? 15.10wily ? 2015-10-22 ? 5.20.2
ubuntu ? 15.04vivid ? 2015-04-23 ? 5.20.2
ubuntu ? 14.10utopic ? 2014-10-23 ? 5.20.0
ubuntu ? 14.04 LTStrusty ? 2014-04-17 ? 5.18.2
ubuntu ? 13.10saucy ? 2013-10-17 ? 5.14.2
ubuntu ? 13.04raring ? 2013-04-25 ? 5.14.2
ubuntu ? 12.10quantal ? 2012-10-18 ? 5.14.2
ubuntu ? 12.04 LTSprecise ? 2012-04-26 ? 5.14.2
ubuntu ? 11.10oneiric ? 2011-10-13 ? 5.12.4
ubuntu ? 11.04natty ? 2011-04-28 ? 5.10.1
ubuntu ? 10.10maverick ? 2010-10-10 ? 5.10.1
ubuntu ? 10.04 LTSlucid ? 2010-04-29 ? 5.10.1
ubuntu ? 9.10karmic ? 2009-10-29 ? 5.10.0
ubuntu ? 9.04jaunty ? 2009-04-23 ? 5.10.0
ubuntu ? 8.10intrepid ? 2008-10-30 ? 5.10.0
ubuntu ? 8.04 LTShardy ? 2008-04-24 ? 5.8.8
ubuntu ? 7.10gutsy ? 2007-10-18 ? 5.8.8
ubuntu ? 7.04feisty ? 2007-04-19 ? 5.8.8
ubuntu ? 6.10edgy ? 2006-10-26 ? 5.8.8
ubuntu ? 6.06 LTSdapper ? 2006-06-01 ? 5.8.7
ubuntu ? 5.10breezy ? 2005-10-13 ? 5.8.7
ubuntu ? 5.04hoary ? 2005-04-08 ? 5.8.4
ubuntu ? 4.10warty ? 2004-10-20 ? 5.8.4


--
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: PSC #025 2021-06-18 minutes [ In reply to ]
On Sun, Jun 27, 2021 at 09:55:24AM +0000, Nicholas Clark wrote:

> ## Supported Platforms
>
> Neil had made good progress in collating feedback on "supported platforms",
> and was close to having a coherent document to propose. The overview is that
> we have 4 tiers, currently described as
>
> 1. Battle tested
> 2. Stable
> 3. Unmaintained
> 4. Unknown
>
> To be in tier 1, a platform needs to provide reliable Continuous
> Integration, so that we get test results promptly for changes made to
> blead. GitHub doesn't offer CI for FreeBSD and OpenBSD, but we'd like to
> make these tier 1, so we need to approach them to ask if they have resources
> we can use.

Cirrus CI has FreeBSD, integrates with Github, and is free for open
source projects:
https://cirrus-ci.org/

Sourcehut has Open and NetBSD but I've not used it at all:
https://man.sr.ht/builds.sr.ht/compatibility.md

--
David Cantrell | Reality Engineer, Ministry of Information
Re: PSC #025 2021-06-18 minutes [ In reply to ]
* David Cantrell <david@cantrell.org.uk> [2021-07-06 12:23:32 +0100]:

> On Sun, Jun 27, 2021 at 09:55:24AM +0000, Nicholas Clark wrote:
>
> > ## Supported Platforms
> >
> > Neil had made good progress in collating feedback on "supported platforms",
> > and was close to having a coherent document to propose. The overview is that
> > we have 4 tiers, currently described as
> >
> > 1. Battle tested
> > 2. Stable
> > 3. Unmaintained
> > 4. Unknown
> >
> > To be in tier 1, a platform needs to provide reliable Continuous
> > Integration, so that we get test results promptly for changes made to
> > blead. GitHub doesn't offer CI for FreeBSD and OpenBSD, but we'd like to
> > make these tier 1, so we need to approach them to ask if they have resources
> > we can use.
>
> Cirrus CI has FreeBSD, integrates with Github, and is free for open
> source projects:
> https://cirrus-ci.org/
>
> Sourcehut has Open and NetBSD but I've not used it at all:
> https://man.sr.ht/builds.sr.ht/compatibility.md

Interesting, thank you, David.

I missed this while discussion, unfortunately - this is good information.

Neil, is there a draft document? I've made some progress on this thing:

https://github.com/oodler577/perldistroinfo/tree/master/pod, which includes
a general document and a detailed document on OpenBSD (thanks to input from
Andrew Fresh).

* https://github.com/oodler577/perldistroinfo/blob/master/pod/perldistroinfo.pod

* https://github.com/oodler577/perldistroinfo/blob/master/pod/perlopenbsdinfo.pod

It includes what I know about FreeBSD (a decent amount), NetBSD/pkgsrc
(not much), Debian/Ubuntu (basic), etc. I've been working on it
when able; but I would not classify it as anywhere near "complete".

I'd be happy to have this information folded into a more general
document or as an addendum that covers, e.g., "battle tested"
platforms. The way these environments have naturally separated in
my research is:

a. perl comes by default (OpenBSD, Debian, e.g.)
b. perl versions are "well supported" (FreeBSD)
c. perl is supported as a native package
d. perl is supported as part of a general package (e.g., pkgsrc, macports,
homebrew, etc)

It's a bit more nuanced than that, but it seems to provide a
complementary perspective to this breakdown: battle tested, etc.
(i.e., one explains "why" a platform may be battle tested; the
other "how" it gets on there; together they tell us "who" would be
affected when making major decisions about versions, releases,
etc).

Anyway, please let me know how we can work together on this. I feel
attacking it from both ends can produce a nice source of fairly
complete information. At the very last, the breakdown ('battle
tested', etc) will provide me with a way to prioritize my research.
Similarly, being able to understand the level of diligence on each
platform paid to perl may affect how well "tested" it may be.

Question - how does this relate to official Perl documentation and
TPF's "documentation committee"? Would this be a perldoc distributed
with a perl version or is this some sort of "internal" documentation?

Thanks,
Brett

>
> --
> David Cantrell | Reality Engineer, Ministry of Information

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native