On Thu, Jan 7, 2010 at 5:36 PM, David E. Wheeler <da...@kineticode.com> wrote: > My hope is that it's full of JFDI! I would be very grateful for feedback and > suggestions.
Thoughts in no particular order: * Limiting to gzip/bzip2 tarballs may screw over Windows users who don't have access to a portable extraction program. (CPAN also supports .zip files.) Perl papers over these cracks with Perl (Archive::*), but PGAN won't have that as an option. * META spec -- don't get too wedded to the CPAN spec until we finish 2.0 and you decide if you still like it. * I don't see how a Makefile can be optional if you need it to build extensions * Don't be specific about update frequency for a search site. "Updated as often as is practical" or something vague like that. (If you implement Andreas fast mirroring system, you can update within minutes!) * PGAN client -- decide if you want to have command arguments like apt-get (e.g. "pgan install Foo") or whether you want to be like cpan without them (e.g. "cpan Foo"); most OS installers seem to use 'install' so either choose that or make your client smart enough to DWIM * Define a "minimum API" between pgan and make, including arguments that all Makefiles must support. You want to avoid the soup of arguments that EU::MM and M::B have built up. Do you need "make installdeps"? Do you need an equivalent to INSTALL_BASE? Standardize these now. * Create a common configuration file with sections for different things like mirrors, commands, etc. Have a 'pgan' section for things that are specific to that particular client only. That way, when someone writes pganplus, it can us the same common configurations [Ed. note: If CT2.0 migration happens on schedule, a common CPAN/PLUS config system may be my QA hackathon project.] -- David
