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]