Just Aristotle and Graham this week.
- This week CVE-2025-40909 was assigned, for an issue we were already tracking (GH #23010). We coordinated during the week to get a fix merged (GH #23019) before 5.41.13. Thanks to Vincent Lefèvre for the report and Leon Timmermans for the fix. During the meeting we discussed getting out security releases for this soon.
- We caught up on release blocker triage. We are tentatively all clear: all previously identified release blockers are now resolved, and there were no new blockers in recent issues and pull requests – except possibly a 32-bit Windows build issue we are not yet certain about. We are keeping an eye on that.
[P5P posting of this summary]
All three of us attended.
- We discussed the situation with
readline and the filehandle error flag once again, starting over by revisiting the basic premise of the error flag. We think we now have a better understanding the overall situation, and this led us to a different approach about how to correct the overall situation, which we will outline as a proposal soon.
- We have been wanting to revert #22465 but wanted to include a testcase that demonstrates why, which we hadn’t gotten to. In order to get this into the looming final dev release, we talked through what the testcase needs to look like, and will submit a pull request ASAP.
- We caught up on new issues and pull requests for release blocker triage. We then reviewed the state of our current release blockers, some of which have been resolved, and one of which (#23026) we demoted based on our new understanding about the
readline situation.
[P5P posting of this summary]
We were all present.
- The status of smartmatch came up. It is in a weird position where it used to be part of the language, then was retroactively declared an experiment, then deprecated and slated for removal, and now it’s no longer being removed – in fact we’ve added a feature for it, and not an experimental one either. The bottom line is that it’s not deprecated any more and not experimental either, but is now just a negative feature like
indirect and multidimensional: it’s a mistake we made that will remain part of older language versions but will not be included in future feature bundles.
- Release blocker triage continues as ever. Quite a few new issues came in recently, of which we identified two issues and one pull request as blockers. One of the issues and the PR pertain to the documentation of the status of smartmatch; we expect that there may be more inconsistencies in the documentation which will need to be ironed out.
[P5P posting of this summary]
A meeting with full attendance.
- We caught up with new issues and pull requests without finding any new release blockers.
- We went over the state of the perldeprecation and perlexperiment POD pages. We found that perlexperiment does not yet reflect the change in direction regarding smartmatch. Other than that we saw nothing to do.
- We went over our options regarding
readline again at length. We concluded that we are not yet sure about the big across-the-board change to I/O functions, and are definitely too far into the release cycle to undertake a fishing expedition. But we don’t want to leave this problem entirely unaddressed during this cycle, and the change proposed by Tony Cook is a strict improvement, even if only a minimal one. So we decided to ship it, possibly with a slightly different implementation that we may suggest.
[P5P posting of this summary]
This extended meeting took place between the three of us in person over several days at the PTS 2025 in the beautiful city of Leipzig.
Release blocker triage continued, across two days. First we caught up with a dozen of new issues and pull requests, of which we identified one more PR as a small release blocker. The majority of our time was then spent considering each release blocker in depth and updating tickets with decisions and/or requests as we went along. A number of small blockers got resolved even during the course of our extended meeting.
While not a blocker, we also discussed the just-reported issue #23238 pointing out that the high-precedence xor operator ^^, added just a few releases ago, was missing an assigning form ^^=. We asked Paul Evans to produce a patch so we could assess its extent, which we received from him the next day, and which we considered to be small enough to attempt shipping in this release.
A significant amount of our time was spent contemplating the situation with readline, as raised in issues #22883 and #23026, with a proposed patch by Tony Cook in #22907. We tentatively concluded that inconsistencies in the entire approach of dealing with the filehandle error flag seem to be at issue, and outlined our thoughts to Tony for feedback. This may necessitate a sizable change of behavior during this release cycle, so a delay of the release is now a possibility. We will continue to assess.
[P5P posting of this summary]
