Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • Say you install an unstable/dev library, and you develop your app with it. You finish testing your app, you're ready to roll it into production, but the *library* hasn't come out of unstable/dev yet. That's what the policy's about.
    • Come on, makes sense? Be serious!

      This billion dollar guys are relying on free software (read CPAN) to do their job and they won't even take the hassle of testing a new version of this module which has been fixed for them and for free???

      Of course, you should release the changes on CPAN, so that they perceive this as "stable". The world is awesomely funny... :)

      • I did say *some* sense, not "perfect sense."

        It's one of the minor peeves I have with CPAN, though: it's not terribly clear to newbies exactly how mere mortals might go about testing a module, or submitting a new release. Those big red "UNAUTHORIZED RELEASE"s are not exactly confidence-inspiring when one is showing one's boss. Especially when one is part of a "billion-dollar company," which is generally synonymous with "hidebound bureaucracy," especially if there's government contracts involved.

        Not saying it
  • It's important not to take on any perceived risk, even if you might get your job done sooner, better, or cheaper. "Policy" is the first resort of the incompetent.

    • Policy is also the resort of people who like to keep their jobs. I know a lot of good people hampered by policy. It's not their fault and it doesn't mean that they are incompetent. Sometimes the good people are merely surrounded by incompetents. :)
      • It's not their fault and it doesn't mean that they are incompetent.

        I don't mean to suggest either one, merely that businesses which adhere to policy over practicality every time should fail, and fail noisily, as warnings to the rest of the world.

    • Right. Perceived risk is the key. Never mind the actual risk.
      • You have to measure actual risk, and that takes valuable time away from avoiding perceived risk.

        See also the "Upfront design me harder!" school of software development.

  • No, they really are developing in a development environment. But the submitter didn't have access to install the module on the development system. And they can't plan on ever releasing the project until your module has been released in production. Managers tend to get unhappy with external dependencies like that.