This week in PSC (225) | 2026-05-18

All three of us attended. We are dealing with a spate of (important, but thankfully relatively small) issues reported late in the cycle, so there will be a 5.43.11 dev release. We do not currently have a release manager for it yet and will ask for volunteers on the list.

[P5P posting of this summary]

This week in PSC (224) | 2026-05-11

All three of us attended further final release preparation. Issue triage continued; a number of small issues came in late, and we merged some of them. We also reverted a late small fix that we had merged recently which turned out to cause problems. Overall we once again left the meeting without open release blockers.

[P5P posting of this summary]

This week in PSC (223) | 2026-05-04

All three of us attended for some more issue triage. We accepted some assorted small fixes and CPAN dual-life module updates. The release blocker list remains empty.

[P5P posting of this summary]

This week in PSC (222) | 2026-04-25

This meeting took place at the Perl Toolchain Summit 2026. All three of us met in person in Vienna and reviewed our release blocker status. Things are in the clear: no new blockers have come in since last meeting, and the previously identified ones are already resolved, with a single exception, namely the workflow for EOL notices in release announcements. Conveniently, Philippe, who just released 5.43.10, is also in attendance in Vienna, and has provided concrete feedback, so this is being addressed.

[P5P posting of this summary]

This week in PSC (221) | 2026-04-13

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]