After two weeks of various people absent on various travels, we got the band back together for a fairly adminstrivial meeting.
Contentious changes freeze has set in, so we will now be monitoring for release blockers. We took stock of the currently open issues and PRs from this release cycle and will be triaging for blockers in the coming weeks.
We need release managers for two more dev releases and the final. Paul will probably take over one of the dev releases. We are figuring out the rest.
[P5P posting of this summary]
All three of us attended.
We spent a long time debating how to proceed with Karl’s proposal to restrict legal identifier names for security. No consensus emerged, and we resolved to ask the question in a venue with wider reach than p5p.
We are faced with an absent maintainer of a CPAN-upstream dual-life module, namely Encode. We discussed this situation in general terms but did not get beyond the question itself – partly due to time constraints. We agreed that this seems likely to occur more often in the future and that p5p will need an agreed way of dealing with it, but what that should be is too big a topic to be contained within the PSC meeting format.
There are multiple PRs currently in flight, some of them rather large, including Paul’s magic v2 and attributes v2. We decided that we are too close to contentious changes freeze in this cycle to merge those.
[P5P posting of this summary]
With Leon at FOSDEM it was only Paul and Aristotle this week, but the discussion ranged widely.
- We have run out of release manager volunteers and need people to step up.
- We briefly reviewed the “confold” discussion. Paul thought his Syntax::Keyword::PhaserExpression might be relevant. We didn’t conclude with any specific consensus and will just continue to watch the thread.
- We discussed the “die on compile with undefined functions” thread. Again there is Paul’s B::LintSubs which does this already, and because of the contrast of historic expectations in the language and anticipated expectations if such a check were added, suggesting the module may be the best way of addressing this. We will continue to watch the thread.
- We discussed the unsatisfactory situation that the CPAN client in core is unsuitable for many users due to excessive memory consumption, which is not easily addressed due to arcane code and a lack of clarity about which aspects of its behavior need to be preserved. This same lack of clarity means that addressing this by a clean-room rewrite of CPAN.pm itself is problematic, but fixing it by implementing a new client faces problems as well: including it in core from the start makes any mistakes costly to clean up, but prototyping it on CPAN raises the question of how a new CPAN client can gain traction. No conclusion was reached but this led to another discussion:
- How do we promote awareness of things on CPAN either as experiments slated for inclusion in core (so we can receive adequate design feedback) or as solutions to requirements for which core Perl is not the right vehicle to address (also a repeated theme during this meeting)? One idea that came up is that we seem to be far too stingy with recommendations of CPAN things in core documentation: recommendations can always be rescinded, without requiring any user code at all to be touched in order to keep working, whereas even the “easiest” things to remove from core do require downstream changes. So we should be generous with recommendations.
[P5P posting of this summary]
All three of us discussed:
- We agree with the general idea of an improved PRNG, so we encourage Scott to continue working on the PR to get it into a polished state ready for merge
- Haarg’s “missing import” PR now looks good; Paul has LGTM’ed it
- TLS in core still remains a goal for the next release cycle.
Crypt::OpenSSL3 might now be in a complete enough state to support a minimal viable product “https” client to be built on top of it, that could be used by an in-core CPAN client
[P5P posting of this summary]
All of us were present.
- We discussed the recent p5p thread about the proposed
class :abstract attribute. Paul wants to write that because it’s a simple addition on current code and avoids design complications about roles. Aristotle doesn’t wish to introduce a new special-purpose feature now that will become redundant when a more general one is available later and wondered whether it can be introduced as roles that currently only support a small subset of features. No call has been made.
- The
class discussions also extended to looking at the meta module and API, and the common idea between the two that it would be useful to get more people to use them and discuss future ideas. We would like people to step forward here.
- We have PR #24059 to implement the retraction of the deprecation of being able to call undefined import methods (and the reinstatement of a default-enabled warning for that case), thanks to haarg. We are keen to get it merged so we will provide feedback soon.
- The maint-votes process came up. We pondered whether we can conceive of something less obscure and will post to the list about this.
[P5P posting of this summary]
