PSC #023 2021-06-04
These are the minutes for *last week’s* Perl Steering Council call. This one is a bit late, but a bit less late than the previous one. I’m getting it done now because Neil has threatened to lap me on this week’s notes!
Term election
The PSC term election is now underway! It began with BooK as the vote administrator, but he was nominated and accepted the nomination so David Golden has taken over. Mostly, we’re just waiting!
Rik’s talk at TPCiC
Rik was scheduled to give a talk at The Perl Conference about the last year of Perl, including v5.34.0, and Nicholas and Neil asked if they could help. Rik said, “I got it!” They did proofread some slides and point out some minor errors, several of which Rik actually remembered to fix!
The talk happened, and is now on YouTube <https://youtu.be/FlGpiS39NMY?t=102>.
C99
We talked about C99 <http://nntp.perl.org/group/perl.perl5.porters/260407> and “supported platforms” once again, and made plans to send emails about both. This felt like it was going to be a nice easy step to move forward and so far, so good.
sort
We discussed the future of “use sort”, which became its own post <http://nntp.perl.org/group/perl.perl5.porters/260355>, already sent.
Dual-Life Sync
We had a discussion about the various ways that dual-life modules fall out of sync with blead. The simplest cases are “a CPAN-upstream distribution was released but not yet imported to blead” and “an upstream blead dist is updated in core but no new CPAN release has been cut. Really, though, it’s a bit of a real mess. Not all “upstream blead” dists are easy to release out of perl5.git. In fact, some have their own repositories from which releases are staged, even though blead is, in theory, their canonical home. They might have multiple bug trackers because of this. Code might be changed in several different places.
We’d like to see this whole process be better managed. We have *some* tooling around “show me if we’re all in sync,” but it’s not good enough, and if it said “we are not”, the next steps are not always clear. We’d like someone to step up to help make this simpler. Right now, we don’t have a spec for what the solution is, and would welcome ideas. If we get no likely ones, we may come back to describe a plausible set of tools.
On a related note, we’re slowly gathering up intel on what upstream-blead dists are managed where so we can try to rationalize things.
RFCs
“Is it time to have the next go at kicking off an RFC process?”
“Yes. <http://nntp.perl.org/group/perl.perl5.porters/260336>“
Code Review policy
Our last attempt <https://www.nntp.perl.org/group/perl.perl5.porters/2021/01/msg258814.html> to get to a clear “we can all agree that X” sort of fell apart. (Alternative take: it wasn’t a slam dunk and other matters got more pressing.)
This section actually got a lot of notes, and I think we need to write up a clear proposal, but the big central questions were:
* When does a committer *need* code review?
* A non-committer always needs code review.
* When does *anybody* need to go through RFC process, rather than just code review?
* How do we make sure the various perlgit/perlhack/etc docs cover this usefully?
Polyfill/namespaces
We talked about which new Perl things are practical for polyfill versions, or other “use after feature release on versions that predate the release.” This conversation necessarily discussed syntax extensibility, the experiments policy, and the question of “put more stuff in non-CORE:: namespaces.”
We also talked about the fact that JavaScript, where we talk most often about polyfills, also fakes up future features with transpilers, not just polyfills. We're not in a great place for transpilation in perl5!
Somewhere, the question came up, “do we want to provide something like experimental.pm that lets you enable an experiment in an old version of perl if-and-only-if it’s the version that is later made non-experimental. For example, “use experimental::safe ‘lexical_subs’” could work on v5.24.0 now that we know v5.26.0 made them non-experimental without change. This was put aside for the moment.
Honestly, there were a *lot* of notes on this. I think Nicholas must have added quite a bit when I wasn’t looking!
--
rjbs
These are the minutes for *last week’s* Perl Steering Council call. This one is a bit late, but a bit less late than the previous one. I’m getting it done now because Neil has threatened to lap me on this week’s notes!
Term election
The PSC term election is now underway! It began with BooK as the vote administrator, but he was nominated and accepted the nomination so David Golden has taken over. Mostly, we’re just waiting!
Rik’s talk at TPCiC
Rik was scheduled to give a talk at The Perl Conference about the last year of Perl, including v5.34.0, and Nicholas and Neil asked if they could help. Rik said, “I got it!” They did proofread some slides and point out some minor errors, several of which Rik actually remembered to fix!
The talk happened, and is now on YouTube <https://youtu.be/FlGpiS39NMY?t=102>.
C99
We talked about C99 <http://nntp.perl.org/group/perl.perl5.porters/260407> and “supported platforms” once again, and made plans to send emails about both. This felt like it was going to be a nice easy step to move forward and so far, so good.
sort
We discussed the future of “use sort”, which became its own post <http://nntp.perl.org/group/perl.perl5.porters/260355>, already sent.
Dual-Life Sync
We had a discussion about the various ways that dual-life modules fall out of sync with blead. The simplest cases are “a CPAN-upstream distribution was released but not yet imported to blead” and “an upstream blead dist is updated in core but no new CPAN release has been cut. Really, though, it’s a bit of a real mess. Not all “upstream blead” dists are easy to release out of perl5.git. In fact, some have their own repositories from which releases are staged, even though blead is, in theory, their canonical home. They might have multiple bug trackers because of this. Code might be changed in several different places.
We’d like to see this whole process be better managed. We have *some* tooling around “show me if we’re all in sync,” but it’s not good enough, and if it said “we are not”, the next steps are not always clear. We’d like someone to step up to help make this simpler. Right now, we don’t have a spec for what the solution is, and would welcome ideas. If we get no likely ones, we may come back to describe a plausible set of tools.
On a related note, we’re slowly gathering up intel on what upstream-blead dists are managed where so we can try to rationalize things.
RFCs
“Is it time to have the next go at kicking off an RFC process?”
“Yes. <http://nntp.perl.org/group/perl.perl5.porters/260336>“
Code Review policy
Our last attempt <https://www.nntp.perl.org/group/perl.perl5.porters/2021/01/msg258814.html> to get to a clear “we can all agree that X” sort of fell apart. (Alternative take: it wasn’t a slam dunk and other matters got more pressing.)
This section actually got a lot of notes, and I think we need to write up a clear proposal, but the big central questions were:
* When does a committer *need* code review?
* A non-committer always needs code review.
* When does *anybody* need to go through RFC process, rather than just code review?
* How do we make sure the various perlgit/perlhack/etc docs cover this usefully?
Polyfill/namespaces
We talked about which new Perl things are practical for polyfill versions, or other “use after feature release on versions that predate the release.” This conversation necessarily discussed syntax extensibility, the experiments policy, and the question of “put more stuff in non-CORE:: namespaces.”
We also talked about the fact that JavaScript, where we talk most often about polyfills, also fakes up future features with transpilers, not just polyfills. We're not in a great place for transpilation in perl5!
Somewhere, the question came up, “do we want to provide something like experimental.pm that lets you enable an experiment in an old version of perl if-and-only-if it’s the version that is later made non-experimental. For example, “use experimental::safe ‘lexical_subs’” could work on v5.24.0 now that we know v5.26.0 made them non-experimental without change. This was put aside for the moment.
Honestly, there were a *lot* of notes on this. I think Nicholas must have added quite a bit when I wasn’t looking!
--
rjbs