On Sat, Jan 28, 2006 at 11:01:06AM -0500, David Golden wrote: > > You need to deal with N/A's down the chain. E.g. I prereq a module that > can't be built in an automated fashion but requires human intervention > or choices or external libraries. If you don't have it and the > automated build to try to get it fails, that really isn't my problem -- > I've been clear about the dependency: "If you have version X.YZ of > Module ABC::DEF, then I promise to pass my tests".
With CPAN::YACSmoke, if you require a distribution that results in a NA report, your distribution is also classed as NA. Part of this is the Perl version issue. CPAN and CPANPLUS will not install your distribution if a pre-requisite up's requirement of Perl. This happened a lot in the last year as ExtUtils::MakeMaker and Module::Starter insert the authors version of Perl when they create a new distributions. As other authors decide to use those distributions without meaning to, they also require that version of Perl. This is the reason I'm looking at developing SDKs for core modules that don't have a life outside the core distribution, to help relieve some of those dependencies. The issue with external libraries and C compiler is awkward to reliably do, as different platforms put them in different places, and often name them differently according versions. This is something I want to try either include into CPAN::YACSmoke, or have a way for authors to create a dependency on an Alien:: or similar distribution, which can determine a version of the require 3rd party software, as well as whether it is installed. > Think about the GD modules -- if the GD library isn't installed, GD > won't build and anything depending on it fails. Should that fail a > "clean_install"? A report should either not be submitted, or it is classed as something that indicates that 3rd party software was not available to complete testing. I'm leaning towards the former. > (Contrast that with SQLite, which installs it for you.) That's because the license enables Matt to do that. Plus it's the kind of self contained release that you can get away with bundling it with the distribution. libgd is used by plenty of other apps. > >A FAIL should ONLY mean that some package has told the smoke system that > >thinks it should be able to pass on your platform, and then it doesn't. > > > >Failures that aren't the fault of the code (platform not compatible, or > >whatever) should be N/A or something else. > > I think better granularity would be: "FAIL" -- failed its own test > suite; "DEPFAIL" -- couldn't get dependencies to pass their test suites; > and "N/A" -- incompatible platform or Perl version or not automatically > chasing dependencies. With CPAN::YACSmoke, a "DEPFAIL" is marked as "ABORTED" and no report is sent. > >If you want to help out, we'd love to see you in irc.perl.net #pita. > > Between tuit shortages and the day job (side q: what's this whole $job > thing I keep seeing in people's posts/blogs), a realtime channel like > IRC is hard to keep up with. Is there a mailing list or wiki or some > such? (Subversion repository?) I'd like to see a mailing list specific for developers of the smoke systems, as currently the ideas for CPAN::YACSmoke are usually just discussed between Robert Rothenberg and myself. If we going to improve reporting it would help to have a wider discussion group. Whenever Robert or I have posted here, it hasn't really reach the right audience. I'm glad that the AUTOMATED_TESTING flag is getting picked up now, but it would be nice to throw those ideas around more often, and getting them refined quicker. I'm looking forward to evaluating PITA, but it will likely have to be on a Perl 5.8.7 Windows box, as my 5.6.1 box can't install any of the PITA distributions on CPAN at the moment, due to the dependency issue ;) Cheers, Barbie.
