All three of us attended this long meeting consisting entirely of dealing with release blockers.
We found no blockers among the issues and patches new since last week.
We weighed up #23676 again and decided that it merits blocker status even though the breakage was the result of a C compiler change, not of a change to perl (in this dev cycle or otherwise).
We then reviewed all of the blockers we were already tracking and made decisions on how to proceed with all of them. Of particular note,
We agreed that #23131 simply cannot be pursued in this form – not just in this cycle but at all. We may eventually be able to virtualize the stash entirely, allowing much deeper optimization by using a more rational internal data structure while maintaing the Perl-land illusion that nothing has changed (effectively turning the stash hash tree into an API in the same way that a tied hash is an API that looks like a data structure). But until such time, Perl-visible changes to the stash data structure are simply too disruptive.
#24340 is part of a series that constitutes a promising-looking fix which we want to pursue, but it didn’t get fully stabilized soon enough in this cycle, and because it’s in a dark and tricky corner of the codebase, we don’t want to take the risk of shipping with undiscovered new breakage there rather than a longstanding bug. Reapplying this patch series early in the next cycle should give it ample time to bake and settle down, and we hope it will eventually ship successfully.
We spent some time debating #24341, tracing commit and issue tracker history to try to assess the correctness of the changes. We lean toward the view that this is breakage that core should fix, but discussion in the comments is ongoing.
[P5P posting of this summary]
We were all present.
- We noted that core team membership votes are concluding on this day.
- We are waiting for voting to conclude before we kick off the discussion about an LLM policy.
- Release blocker triage continues. We are now fully caught up and marked a few more issues as blockers – all of them minor.
- We unmarked several issues as blockers and marked #23131 as such instead, because it was the root cause for them all. We then spent a long time deliberating what to do about it and debating approaches. We have not reached a conclusion yet and will be keeping an eye on it.
[P5P posting of this summary]
All three of us attended.
We discussed policy questions that were turned up by the recent submission of some LLM-generated PRs. We need to hold conversation about this among the Core team. No contributions of this kind will be accepted while the discussion is still ongoing.
We finally had a good chunk of time to spend on release blocker triage. We made quick progress, working through half our list and closing some issues in the process. We newly marked 4 issues as blockers.
[P5P posting of this summary]
All three of us attended this long meeting covering quite a bit ground:
CVE-2026-3381 obliges us to cut a 5.42.2 point release with an updated Compress::Raw::Zlib.
We accepted Philippe’s and Eric’s offer to handle the last dev releases of the cycle.
Olaf Alders requested more explicit EOL notices and has updated perlpolicy.pod and the release manager guide accordingly. We agreed that the release announcement mails for the final dev release and the stable release should also contain a brief note about the perl version which is falling out of support, and filed an issue to make this happen.
We sent mail to kick off the voting process for some new core team member candidates.
We discussed the state of Devel::PPPort. It has been outdated for some time and needs to be unstuck.
We would like to get customize.dat down to the only entry that cannot be removed (for version.pm). We will try to coordinate with maintainers.
We noticed that we missed the deprecation of multiple use VERSION declarations in the same scope, which was supposed to be fatalized in 5.44. It is too late now to do that in this dev cycle, so the warning will have to change to 5.46 and the deprecation revisited next cycle.
Further on the topic of overlooked deprecations, we considered how to prevent this from continuing to happen. We decided that some kind of documentation of recurring PSC obligations during a cycle is needed, which would also include things like the contentious changes freeze and release blocker triage.
There was not much time left for release blocker triage, so we only did a little, which surfaced no candidate blockers so far. (A few already-definite blockers have been spotted and marked outside of triage.)
[P5P posting of this summary]
All three of us were present for a quick meeting.
We discussed the progress of our outreach to some potential new core team members. We will be holding a vote once we hear back from everyone.
We noticed that a minor step in the PSC transition was missed during this cycle. We agreed that there needs to be a checklist for the procedure, and we intend to write it up.
We started with the release blocker triage, but the meeting was short so we didn’t look at many issues. We have no candidate blockers so far.
[P5P posting of this summary]
