Several hours ago my unorthodox campaign came to an unsuccessful end. There has been a lot of feedback to my previous post, some of it so surprisingly off the mark that I still have not wrapped my head around it enough for a proper response. I plan to publish a much more in-depth analysis and "lessons learned", but I need to gain much more distance from the current hot mess of CPAN, to better express the crux of what went right and what went wrong (spoiler - while the campaign itself failed, I consider the chain of events an incredible, way-beyond-what-I-expected success)
Couple weeks before the "I give up" announcement I compiled and started working in parallel on the following list, in order to shape up a "final ribasushi-approved" DBIC release:
( If you want the text below narrated instead - watch the video, there is also an alternative comment thread on reddit )
On the 1st of October I launched a daring crowdfunding campaign. I asked over thirty companies directly relying on my open source work to split a rather modest bill, allowing me to exclusively focus for at least a year on several key parts of the Perl5 library repository (CPAN). Two months later, after a really promising start, the campaign is effectively dead.
If you have been browsing MetaCPAN lately, you may have noticed a new shiny red
ball ribbon on the left side of some distibution pages. What you may not have realized is that this is a generic feature, and you can add one to your distribution just as easily.
TL;DR: All you need to do is add an IRC resource to your metadata:
In the recent year I notice more and more instances that mail to email@example.com is silently swallowed. I know this because I communicate with the senders through other channels, and I've even received forwards of copies of emails which as far as the sender is concerned are delivered. I am also increasingly hearing the same story from my PAUSE-peers. Bottom line: it seems that the SMTPD cpan.mx.develooper.com is configured to do rather aggressive *silent* spam filtering.
I am writing this for 2 reasons:
- I want to gauge whether the problem is indeed pervasive, …
If you use DBIx::Class in a production setting and just happen to have a substantial test suite - this post is for you.
TL;DR: Recent development in DBIC required the introduction of a subsystem that turned out to be much more complex than initially envisioned. While it *seems* that all the kinks have been worked out, the failure modes are so un-graceful (dis-graceful?) that the latest trial is in need of extra testing before it can be deemed ready for production.
Therefore if you are in a position to validate that everything behaves as expected, without the risk of taking your production to the fjords (did I mention substantial test suites?) - please help those in less favorable situations and test the thing before it goes live.
You can install the trial by any of the following methods:
HARNESS_OPTIONS=j4 cpan R/RI/RIBASUSHI/DBIx-Class-0.082700_06.tar.gz
HARNESS_OPTIONS=j4 cpanm -v DBIx::Class@0.082700_06
or by grabbing the tarball and doing it old school
While the current version is deemed safe, I am being extra cautious because of recent history. So what exactly happened (and what went wrong)?