Maybe I wasn't clear enough: if blead breaks some module on CPAN that's 'fine'. But the problem wasn't blead but releasing a new version of Carp to CPAN which broke all stable Perl version installations. I don't see how a blead smoke prevents that from happening for a dual-lifed module. A warning in the Carp changelog would have helped (I read all changelogs before upgrading modules) if it was known at the time of release. This kind of problem could only be solved by rerunning the tests of all downstream dependencies of a module after it has been updated which would require the test suites installed or redownloaded from CPAN. -Alex (abraxxa) On Wed, Feb 29, 2012 at 4:46 PM, George Greer <perl@greerga.m-l.org> wrote: > On Wed, 29 Feb 2012, Nicholas Clark wrote: > > The thing that *would* have got it is a "build all of CPAN", which we >> don't >> have the resources to do for every change. So it gets down to - how do we >> spot which changes need that sort of thing? >> > > If I can get a copy of the "build all of CPAN" script that the comparisons > from a while ago were done with, I can try to set it up on a rolling basis. > That is, it would compare blead from the last pass with whatever was blead > at the start of the next pass. So it wouldn't be every change but it would > at least be more than never. > > > Should then *all* changes go through a smoke-me change? I treat all of >>> >> >> I'd actually be happy if (nearly) all non-doc changes *did*. But it >> wouldn't >> have caught this one. >> >> (We'd need to improve the smoke-me reporting infrastructure to make this >> useful though) >> > > What's on your wishlist? > > -- > George Greer >Thread Previous | Thread Next