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.

cpan6 - moving forward 5 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • A while back I speculated on the various proposals for a "CPAN Replacement" I saw and mentioned that it appeared to me that there was a lack of planning.

    Mark asked me to not comment on CPAN6 until after the release at YAPC::EU and gave me an early copy of the paper, and I've happily done so.

    But reading through the final version of the paper, some concerns remain.

    Without wanting to get too much into specifics, I was wondering how you plan to deal with this type of thing. I see a lot of detail on what your so

    • I see a lot of detail on what your solution looks like, but not so much detail on things like the underlying reason for it's existance, use cases, constraints, assumptions, priorities, and so on and so forth.

      The "Emerging problems" section of the Global Design Document [cpan6.org] cover a lot of the shortcomings of the current CPAN. Also see the section "Projects" in the chapter "Pause6 Organization" for some more examples.

      How do you plan to deal with these sorts of issues ... and how willing are you to change

      • The setup you have there makes it really hard...

        I'm already on a billion mailing lists, unless you plan to have it go onto nntp.perl.org I really don't want to be on two more.

        I don't know how I'm supposed to generate patches to a postscript file (why isn't everyhing just text or HTML) and in any case, I'm useless with patches, and so is Windows.

        Not to mention I can't actually read the postscript file on this system.

        OK, I may be bitching here, but if 90% of the computer users can't play nicely without projec
        • I agree with Adam. I'm not sure how you selected Jarkko and Adam to be the early reviewers of the paper, but it seems to me that Andreas might have something good to say, and that the current PAUSE admins might have had a lot of wisdom to add. My first inkling that anything was happening is when someone subscribed me to the CPAN6 mailing lists. I suppose that's a nice jesture, but no personal note accompanied the subscriptions, and I promptly unsubscribed. I don't do mailing lists. Put it on nntp.perl.org and then I can deal with it.

          My initial reaction to the project, much like Adam's, is that I don't have time to deal with a new system, I don't want to be on more mailing lists, and that the design documents were much too large to be useful. The only thing we really need right now is a way to store distributions in a file system so that the kooky Perl 6 module selection (with author, version, and source) can work. I didn't see anything about that. Once we can store things, we can build things on top of that.

          The design focuses mostly on module users, and is very unattractive to me as a module author and PAUSE admin. It sounds like a lot of work. CPAN works for me because I don't have to do a lot of work.

          Furthermore, I don't suspect that most of the "security" additions will not actually help those people who are in environments that forbid CPAN use. In my work with Stonehenge I've talked to a lot of different people in many different companies and situations, and none of them had ever said anything about wanting those sorts of features. Sure, those features may be more like various linux things, but these people also are usually stuck with a vendor configuration for their operating system too and can't install external packages for linux either. Even if Tim Bunce signed all his DBI dists with his private key, the IT managers are still going to ask "Who the hell is Tom Bunce, who's selling the support contract, and who do we sue?" These are not issues technology will not solve.

          Elaine mentioned that CPAN worked because Jarkko JFDI. I've been part of discussion for the local Python group about a CPyAN, and they get into the same design phase you've done. Notice that Python still doesn't have CPyAN.

          I'd rather not see another design-by-committee project, especially if a lot of the work is going to happen in secret. Coming up with a prototype on your own and showing it to everyone is one thing, but planning the future of everyone's module use without getting everyone's input is a bit odd.

          • I'm not sure how you selected Jarkko and Adam to be the early reviewers of the paper, but it seems to me that Andreas might have something good to say,

            Mark has been in contact with Andreas along the way.

            ... and that the current PAUSE admins might have had a lot of wisdom to add.

            We basically sent it to the people who asked for it. We have taken the initial design, subjected it to review and now we are asking the wider community for input. There's no point in releasing something before it is ready

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.