We accepted a number of last-minute patches provided by Karl to improve our z/OS support stance, since they are strictly limited to that system and largely touch things that were broken there anyway.
The worrying situation on CPAN Testers for the latest HTTP::Tiny situation cleared up; it was only caused by smokers-only tests against a live system that was intermittently unresponsive. Consequently we have now synchronized with CPAN, which means every one of the late-in-cycle release blockers we had is now addressed.
Leon had already begun work on RC1 even before that.
We touched base on LLM policy based on the feedback we have had on the thread so far. We have been chewing on some thoughts about that which are in draft state; we agreed that we should actually send them out soon.
We discussed one of the two new PPC PRs, about viral value magic, which Leon and Aristotle realized is more similar to tainting and its limitations than previously understood. No verdict was reached; we will continue this discussion.
GTC 2.20 brings a huge amount of new features again (described in this post) and is starting an additional, more trimmed down, high level API, geared more toward what designers expect. But it also comes with new documentation and error handling, the two most important things that were missing for a professional distribution.
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.
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 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.
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.
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
This post is adapted from my notes and recollection of the welcome
speech I gave on the morning of Thursday April 23, 2026, just before the
initial stand-up.
This post is brought to you by
Geizhals Preisvergleich,
a Gold sponsor for the Perl Toolchain Summit 2026.
You can learn more about Geizhals at the end of this article.
This year, I was once again honored to be invited to the Perl Toolchain Summit (PTS), held in Vienna. Following productive years in Lisbon and Leipzig, the CPAN Security Group (CPANSec) spent time discussing how to improve the security of the Perl and CPAN ecosystem.
As always, the magic of PTS lies in the hallway discussions and focused groups where we can work on complex problems that are nearly impossible to coordinate over email or GitHub alone.
CPANSec: Maturing our CNA Role
Since we established CPANSec as a CVE Numbering Authority (CNA) in 2025, our focus has shifted toward efficiency and sustainability. We have a small group working on finding and documenting vulnerabilities. We spent time in Vienna discussing:
