schmorp recently complained about a maintainer fail in Math::BigFloat, and since this is not an isolated incident of the last years, I try to give a summary of all the maintainer fails of important modules lately, as I happen to fix them privately.

Problems in core ext/ and dist/ modules, maintained by p5p:

These are all doomed modules, as p5p refuses to take bug and security reports, and most of them are not maintained and fixed and improved in cperl only.

Math::BigFloat

Maintained by p5p, responsible: pjacklam

regression in blsflt (left shift) and refusal to fix it, lack of understanding of float math.

fixed in cperl only. in cperl we also heavily modernized all the bigint/bignum/bigrat/Big::* modules to use typed signatures.

there were several podcheck fails, which were promptly fixed. so they do react fast, their only problem is the lack of understanding.

Storable

maintained by p5p, responsible: nobody

missing features, grave security problems with bless and tie, other security problems on 64bit with overlarge hashes and names. fixed in cperl only.

tonyc recently replied to a similar but limited bugreport with a partial fix, which doesn't really help.

Net::Ping

unmaintained by p5p, responsible: nobody, previously smpeters

p5p took it over from him, while smpeters refactored the test suite for a while. many bug reports and patches still sitting in the cpan queue, no idea about the p5p queue, because they blocked me there.

development stalled, so I added most needed features and fixes. fixed in cperl, and on https://github.com/rurban/Net-Ping

ExtUtils::Constant

unmaintained by nwclark, responsible: nobody

Development and maintenance stalled, many fixes unanswered. I had to publish all fixes to cpan as UNAUTHORIZED RELEASE.

Fixed in cperl.

Opcode

unmaintained by rgs

Development and maintenance stalled, many improvements ignored. had to publish my own version Opcodes. Maintainer only wants Opcode as parent module for Safe, but not to specify Opcode properties. This is hardly an acceptable point of view.

POSIX

maintained by p5p

Basically this module is only plagued by old sins, exporting all symbols at once and not by request. But the maintainers obviously don't know about this and accepted a bugreport that a new symbol is not automatically exported. This is a feature, not a bug.

The unsafe tmpnam is still exported, but at least deprecated. The new tmpnam replacements tmpfile, mkstemp, mkdtemp are missing.

POSIX::1003 should be used instead.

Problems in core cpan/ modules, maintained by various:

autodie

maintained by pjf, several private core fixes, several unfixed problems

this is a stable pragma with a complicated scoped feature set, which does not really work in corner cases. it broke the compiler with gensyms and empty stashes, and it broke Porting/sync-with-cpan. no autodie does not properly restore system() from CORE::. I had to remove autodie from cperl's improved sync-with-cpan, and I urge everybody else not to use it, as the errors are often invisible and undetected.

It is also considered bad practice to use it. You need to know which open can fail and which not. It's recommended for complete newbies, such as use warnings and Carp, which introduce heavy memory regressions.

Socket

maintained by pevans, but this guy can usually be trusted.

The queue is quite small.

But I had to add missing IPv6 constants in cperl for Net::Ping, a lot more are still missing for ping6 functionality. http://search.cpan.org/~rurban/Socket-2.021_01/

JSON::PP

unmaintained by makamaka

unwilling to support Cpanel::JSON::XS the follower to the broken JSON::XS

unwilling to support cross-compatibility with the other JSON modules, throws several redefinition warnings if the loading order is different.

unresponsive. we typically wait >1 year to get answers on feature requests. last release 2013.

in cperl we fixed overload stringify and eq as in Cpanel:JSON::XS esp. "true" => true not 1

Pod::Perldoc

now maintained by mallen

not much problems, but horrible perldoc.3 vs perldoc.1 conflicts in core integration.

podlators

horrible core integration of Pod::Man and a broken $Maintainers{MAP}

Pod::Simple

Properly maintained, but they still think they are alone on this world, same problem as with Ingy. That there is only one installed perl, and only this can run the tests. There exists $^X for a reason.

I fixed their t/search50.t test in Dec 2015, but it is still not handled.

Since cperl will ship its own heavily modernized version, it's no big deal. signature all the methods and get type violations at compile time, which caught many errors already.

ExtUtils-MakeMaker

maintained by the toolchain gang

I don't expect the toolchain folks to support the cperl variant, so I do it by myself, and added various new features along the line.

wrong Config dependencies, support PERL_USE_UNSAFE_INC=1, call darwin dsymutil with DEBUGGING, use the fixed and faster YAML and JSON cperl core parsers. see below at Problems in core toolchain cpan modules, kept fixes private.

Test-Simple

maintained by exodist, very sceptical

The big Test2 feature he is working on for 2 years is event-based streamable tests, which still is 2x slower so far. So a no go. See http://search.cpan.org/~exodist/Test-Simple-1.302014_007/lib/Test2/Transition.pod

The old implementation is too heavy, we simplified and improved it internally. Since cperl will ship its own heavily modernized version, it's no big deal. We improved many abstraction methods. Signature all the methods and get type violations at compile time, which caught many errors already. Some of our type checks will break your tests, esp. that the skip count needs to be a number.

Digest::MD5

maintained by gisle, no response

core had traditionally a wrong U32_ALIGNMENT_REQUIRED probe in Configure.

I added a proper probe to fix the intel architecture, and added compatible SIGBUS on alignment fails, to detect previously undetected alignment errors. Fixed 64bit and darwin multiarch probes. Fixed RT #77919

https://github.com/rurban/digest-md5/tree/intel-align-rt77919

Devel-PPPort

unmaintained by alh

Had to fix 5.16 binary names by myself, which should have happened in the last 8 years, as p5p pushed for binary names, and I opposed it.

cperl also supports @INC without . (-Dfortify_inc)

See https://github.com/rurban/Devel-PPPort/tree/516gvhv

Scalar-List-Utils

maintained by pevans

Many core features are improperly supported, and many features are missing, so people had to come up with List::MoreUtils. The current maintainers do not known about MULTICALL and lexical $_, the most trivial features needed for this module.

The recent div by zero fix was done much worse than in cperl.

At least he is responsive.

Config::Perl::V

Only minor issues. This is the only core module published as .tgz, so it cannot be updated by p5p with sync-with-cpan. only fixed in cperl.

Problems in core toolchain cpan modules, kept fixes private

Basically all toolchain modules which lack cperl support. Esp. the 'c' suffix version detection and comparison, and the lack of knowledge about cperl builtin modules without .pm: XSLoader, DynaLoader, strict, coretypes. The old toolchain still wants to install a missing XSLoader requirement, because it searches for modules statically, not dynamically.

CPAN-Meta-YAML, CPAN-Meta-Requirements, version, CPAN, CPAN-Meta, Parse-CPAN-Meta, EU-MM

The biggest problem is over-architecture, as the toolchain is typically the gathering place for all the important people too incompetent to do core. The old master Dan Golden is the only light in the dark.

Another problem is the lack of efficient JSON and esp. YAML support, and lack of YAML compliance. They gave up on YAML instead of fixing it, as we did.

With cperl we added fast XS variants for JSON and YAML, fixed the broken and overly strict YAML::XS, and use this throughout. And not the infant YAML::Tiny, which also deviates from the YAML specs. cperl added JSON and YAML validation tests for all existing JSON and YAML modules.

Problems in other cpan modules, maintained by various:

I've looked over all my >100 distroprefs patches, and in the end problems are only with ether and schmorp. schmorp at least knows what he is doing and eventually comes up with fixes by himself.

Moose

maintained by ether

Moose was compilable before ether took over, since then it eroded. The maintainer doesn't have an idea how compile-time vs run-time works, which should be critical understanding for such a compile-time optimized module.

A lot of compile-time code is not run in BEGIN or CHECK blocks, rather as main_cv code of compile-time imported modules, which does not work when separated into compiled and run-time.

I didn't even bother to file a ticket, as 1st compared to Mouse Moose is totally unusable, and 2nd the maintainer might be willing to fix it, but is not able to maintain this.

Sub::Name

maintained by ether

The new maintainer is not able to come up with 5.16 support, binary names. She refused to merge my fixes for several years.

B::Utils

maintained and taken over by ether. I suspect a hostile takeover.

The new maintainer was not able to maintain API stability for OP::parent, one of the biggest reasons this module exists, and lied for the reasons to take it over. A complete disaster. I had to publish my own stable B::Utils1 module.

Summary

So in summary, only p5p and ether are failing to do their job.

With the core cpan modules there are some typical outliers, nothing dramatic. cpan itself looks very healthy, whilst p5p looks totally dead.