This week we had to reschedule to Tuesday in order to attend in full strength.
Release blocker triage continues and fortunately has not turned up anything new, but unfortunately has not delivered full resolution of already-known issues either: CPAN Testers says that HTTP::Tiny 0.096 is not a shoe-in, as we had hoped. We will have to evaluate the reports more closely.
We nevertheless intend to begin work on RC0, since it mostly consists of writing the perldelta.
None of us had time to spend on the LLM policy discussion this week.
We discussed the twonew PPC PRs in very general terms but need to return to them in more depth next week.
So I've created a programming language which blends a fairly JavaScript-like syntax with fairly Perl-like semantics, and a few other features that I haven't really seen in many programming languages.
This Perl:
use Path::Tiny;
my $str = uc(substr(Path::Tiny->new("myfile.txt")->slurp_utf8, 0, 80));
Becomes this in ZuzuScript:
from std/path import Path;
let str := new Path("myfile.txt")
▷ ^^.slurp_utf8
▷ ^^[0:80]
▷ uc ^^;
The ▷ operator means "evaluate the left side, then evaluate the right side with ^^ set to the result of the left side". It's conceptually similar to | in shells and seems to make a lot of expressions so much easier to understand.
5.43.11 has so far turned up a few problems, thankfully small. As a result there are new versions of Archive::Tar and HTTP::Tiny to sync, which we intend to merge.
We decided how to proceed with our schedule: we will wait another week for any other findings in 5.43.11, and if nothing else shows up then we intend to start working on 5.44.0-RC0 at that point.
Then here is a reminder that in light of current events you will want to update your account to use a different email address. (There are about 130 of you that get to jump through this hoop now.)
This week we were back to full strength. We have now dealt with all of the belated issues and all of the blockers. Paul will be shipping 5.43.11 very shortly. With the amount of changes we have had to merge, we will not be able to rush the .11 cycle, but we intend to start the work on the 5.44 RC early, to ensure that we can release with as little additional delay as possible.
This post is the first in a series that will follow my re-development of the Devel::ptkdb debugger. This post explains the beginnings of my involvement with the Perl Tk debugger.
Paul is away this week so only Leon and Aristotle were present. A number of the belated-for-this-cycle issues have been addressed this week and we are following up on the remaining ones. We do not yet have a firm commitment for the release manager for 5.43.11.
I was once again privileged to be able to attend this year's Perl Toolchain Summit. This is the 13th year (in a row if you discount the Covid years) that I have been able to attend and it is the technical highlight of my year.
This year the event was held in Vienna and, for the first time, my wife accompanied me. We took a direct train from Zürich to Vienna and had a wonderful trip through the glorious Swiss and Austrian countrysides.
We arrived fairly late on Wednesday evening so didn't meet up with anyone then, but we saw a few of the other attendees at breakfast the next morning, and then I set off for the venue where I met up with everyone else, heard BooK's opening speech, took part in the introductions and then split off into a room with the MetaCPAN group with whom I spent about half of my time. Meanwhile, my wife set off to explore Vienna.
A quick summary of what I got up to at PTS 2026 in Vienna.
Test::Smoke's long-term future. I had several useful discussions with H. Merijn Brand (Tux) and Todd Rinaldo (toddr) about keeping Test::Smoke maintainable for the long term. This tied directly into the MetaCPAN hosting migration below: DigitalOcean offers managed Postgres, Hetzner doesn't, and Test::Smoke's existing database usage wasn't especially efficient. The outcome was toddr starting a rewrite that runs as a single container backed by SQLite and local files -- much more portable and easier to operate.
Migrating MetaCPAN from DigitalOcean to Hetzner. I spent a big chunk of the summit pairing with Shawn Sorichetti (hide) on the migration, including reorganising our Kubernetes setup so it deals more cleanly with multiple environments. Shawn was making a large number of changes; I focused on reviewing them quickly so we could iterate fast.
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.
At the most recent Perl Tool Chain Summit (PTS) in Vienna we decided to deprecate Module::Signature. Module::Signature has been around for a long time but it has become increasingly clear that it does not provide the security assurances that it was designed to deliver.
Dist::Zilla::Plugin::SigStore::SignRelease is a new plugin that signs your CPAN release with SigStore before uploading. SigStore uses short-lived, OIDC-issued certificates. You authenticate with Google, GitHub, or Microsoft, and cosign produces a signature bundle. No long-lived keys, no keyserver dance.
How it works
The plugin extends the Dist::Zilla plugin UploadToCPAN. During the dzil release, it:
Calls cosign sign-blob on your release archive, producing a .sigstore.json bundle file.
Pulls the certificate out of the bundle and verifies the signature locally before anything leaves your machine.
Hai again, after a very productive three weeks I can announce the next major release of Graphics::Toolkit::Color (despite the rather small version number jump). In this post I explain what changed(+12 spaces, +1 method, +7 method args), why it is relevant and how I used LLMs to achieve that.
At the 2026 Perl Toolchain SummitSalve Nilsen and I proposed some ideas that we have been discussing on and off for the past several months for CPANSec, for a CPAN Meta v3 Specification.
Why does the specification need to be extended?
Version 2 of the CPAN Meta Spec (CPAN distributio
n metadata specification) is does not allow the addition of new data, except using fields prefixed by "x_".
However, there is a need to include additional metadata about:
external dependencies (services, libraries, files, or environment variable)
embedded external libraries, e.g. zlib or bootstrap.
licensing
vulnerability reporting
parent-child relationships (e.g. forked project)
fixed vulnerabilities in this fork or in embedded libraries
code and documentation generated through automation or using LLMs
how and where to report security vulnerabilities
project funding and sponsorship
how the project is supported by the maintainers
enumeration of community health documents, e.g. SECURITY.md, GOVERNANCE.md and AI_POLICY.md
