Then here is a reminder that 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.
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.
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.
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.
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 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:
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.
CPAN Testers produce a lot of data. Every CPAN distribution gets tested by our volunteers almost immediately after upload. These testers run every version of Perl across every platform you can imagine, and some you never knew existed. Instead of each project maintaining its own testing environments, the community maintains these systems so the project developers can focus on developing their project. There are more than 150 million test reports so far, and that number currently grows by about one million every month.
Sorting through all of those test reports is a big job. The community helps: Slaven Rezić, Andreas König, and others regularly submit tickets to a project's bug tracker for problems revealed by the testing systems they maintain. And individual maintainers can visit one of the UIs to view the data like the CPAN Testers Matrix (by Slaven) or CPAN Testers Magpie (by Scott Baker). But this, too, is a lot of manual effort.
Well, not all of it ... yet. But some of it has been rewritten many times in many languages and "all" of it will be rewritten in many more languages. Of course "all" will never be reached, so it will be an ongoing endeavor, but at least you know the goalposts.
You can read it at https://perl.petamem.com/docs/eng/, and the language picker in the upper right hand corner will tell you, more honestly than any sentence in this post can, where the public-facing part of the work currently stands.
As already reported, I'm writing this color library. Recently I created my own test function for it. And since it was easier that I thought, I want to show you how, so you can write your own!
Please share this post, the powers that be rage against us; you will not see any post regarding our activities in Perl Weekly!
Update: We got in Perl Weekly this week, but not for the right reasons. I hope in the future this will not be repeated or necessary. Thanks to the Perl Weekly editor who included this announcement. Special acknowledgement to David Cross for heading up the negotiations.
If you wish to comment about this post, please do so at r/perlcommunity.
Perl Community / Science Perl Committee Impact in 2025
Talks Delivered at Winter 2025 Perl Community Conference in Austin, TX
Video editing in progress, will be released after the 2026 Summer PPC.
It used to be so that a repository was only a place of work
and the distribution was the actual result of that work.
Only the contents of the distribution mattered. People would
read the files README and INSTALL from the distribution
after having downloaded it.
Not so anymore. Today the repository is out in the open in
GitHub,
GitLab,
Codeberg
or other shared hosting site.
On the other hand, the documentation in the distribution is often
discarded as distribution packages are rarely downloaded manually
but rather via a package manager which installs them automatically.
Publicly viewable repository has in fact become much more
than just a place of work. It is also an advertisement
for the project and of the community behind it, if there is
more than one author or contributor.
Use AI. Use it more and better. If you are not yet equipped to use it
well - that is fine, learning takes time - but please do not inhibit
those in the community who are.
That is the whole argument. The rest of this piece is why I think it
is correct, and why I think the current register of the Perl community
around this topic is costing us something specific and avoidable.