Nice! But why does that page say "August 1999 - September 2013"? Makes it look somewhat out of date even if the content is almost real-time.
316 : INGY [2014-08-16] 60 : KENTNL [2014-08-16] 52 : SHARYANTO [2014-08-16] 42 : ETHER [2014-08-16] 42 : PERFSONAR [2008-01-16]]]>
---
What's even more spectacular is that in those 24 hours and with 317 releases, your fancy new release tool didn't catch that most of them -- of which a majority looks more like (meta-)care-taking than bug fixing or improvement, and let's not forget those introducing-a-bug-and-fix-it-5-minutes-later combos -- won't even install on a fresh Perl setup. But I guess it's great that you can release "about 5-40 times a day!"
I was really looking forward to contributing to this CPAN Day and was that close to release my first distribution, but after a few hours watching all these meaningless commits just killed the mood.
If it's going to be a trend in the Perl community to celebrate quantity over quality on the CPAN, I think I'll stick to doing my occasional PRs when I find a bug and pushing some code on github in case anyone is interested.
But yeah, I guess congratulations are in order.
]]>But mostly I'm impressed because the CPAN "system" worked and all the folks who contributed put it through its paces to celebrate. If CPAN day becomes a tradition it would be a good thing.
]]>The "DEVREL" prefix will be appended as soon as there is *anything* in the chain that is, well - a devrel as understood by PAUSE. Then filtering these results in the consumers will be beyond trivial, while the metabase infrastructure itself won't need much tweaking at all.
]]>Failures due to alpha versions of Test::More should not be red marks against OTHER modules that in no way took action to cause the problem.
If I had known they did show up there I probably would have been reluctant to release these alphas. The alphas are valuable and help me find a lot of issues... but I don't want other people to be dinged from them. I myself judge modules based on the pass/fail ratio in cpan testers.
At the very least these should be unknown, not fail (in metacpan/cpan display) At best they would be a fourth category that probably should not even be displayed without asking for it.
As for calling my changes overzealous, time will tell, I have no intention of marking it stable until the perl-qa and toolchain gangs are onboard, hopefully that level of approval works for everyone. I never had any plans to release this as stable without lots and lots of eyes double-checking me.
]]>I like this a lot, and it's similar to what I was thinking too. However, I realize now there's a problem here -- the release status of a module can't always be determined from the module itself (at least, not the $VERSION) - you need the distribution metadata to determine that.
There is one (relatively) simple way to handle misdirected failures, however -- allow a mechanism to redirect them. We've already got nearly that, with the new admin site -- just modify the interface to allow redirecting the report back to the tester, *or* to the author of a different module. I know I've certainly received FAIL reports where it's determinable from the test output that some other module was at fault, so it would be nice to be able to send that report directly to that module's queue instead.
]]>I am the one making these Test::More changes, and I would have been a lot more reluctant to make these alpha releases if I know it would give other people red marks. I myself judge modules based on red vs green counts.
In addition I do not believe (given I know and admire the skill of everyone involved) that the current stack is written so badly, that it will be a monumental effort to allow for "super-namespacing" of the test results. At worst it should be a couple day slog, perfect for a hackathon... if there only was an upcoming one ;)
The workarounds otherwise proposed in this thread are... well - workarounds for the real problem.
]]>