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]