Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Just stray thought;

    Would it be sensible to have some kind of "re-testing" infrastructure? E.g. when testing some new module before upgrade, one also checks if there are any other packages that would like re-testing, but with the upgraded version.

    I'm thinking this "re-testing" would at least give authors a faster feedback, presumably reducing the necessity for downgrading in the long run. :)

    • Retesting would likely involve installing tests alongside the code, something we've never done before. It's been discussed, but no action taken.

      Regrettably, when we have a bug crop up in our code, it's often difficult to find it without checking out an old branch and our CPAN dependencies are in a different checkout. I believe that svn externals would alleviate some of this pain, to be honest, but I'd still like to see "authority" become a first class concept on the CPAN (sort of the same way I'd like to

      • My question is why are your dependencies in a different checkout? We've got a directory with all versions of any CPAN dependencies we've ever used, but it's just a flat directory and simply acts as a central place for different projects to copy things from.

        Each project has its own DarkPAN and we point CPAN(PLUS)? at that. When we want to change the version of something, we just "svn rm" the current version in the project's DPAN, "svn cp" the tarball from the central directory, and rebuild the indexes.

        • My question is why are your dependencies in a different checkout?

          This was set up long before I arrived here :/