* Daniel Carrera (daniel.carr...@theingots.org) [090529 11:42]:
> Timothy S. Nelson wrote:
>>     While I've no objection to building the end-user software to 
>> support multiple repositories, I know that there are certain segments 
>> of the community who are very very keen to keep everything in the one  
>> repository.
>
> After reading the Zen of Comprehensive Archive Networks (ZCAN), I think  
> there is very good reason for retaining the current infrastructure with  
> the current, large, set of mirrors. That is not to say that we can't  
> upgrade the packages and metadata.

It also says:
  "Another important credo is: Avoid bottlenecks and interdependencies.
  Decentralize. Create and encourage alternatives."

When reading the ZCAN, be very aware that it discusses CPAN. As users of
CPAN, we all know that it works (for the moment).  But that should never
be a reason the think outside that box of daily practice!  When making a
step in development, first figure out which components of CPAN are really
valuable, which are outdated, and which are missing.  Then keep the good,
salvage the outdated and fill-in the missing.

Just to give you something to think of: with the current speed of
networks and price of hardware, you do not need a huge network of
daily synchronizing mirrors but a sufficiently large network of very
up-to-date mirrors.  Preferrably smart mirrors, which can answer
(Ajax-like) some simple questions about distributions, such that you
do not have to download the immensely growing 02packages.details files
anymore.

Ftp-mirror sync trees.  If you add subtrees on your disk which contain
different archives or targets, then these will get mirrored as well.

> "CPAN shall not piggyback another language" -- from ZCAN.
> Judging from the ZCAN page, I don't expect that uploading Ruby modules  
> to CPAN will go well, even if that module can be compiled to Parrot. The  
> ZCAN page gave good reasons for this.

Agreed: do not merge sets of unrelated data! Perl6 and Perl5 are
unrelated sets of data.  The only relation is the people who use it.
-- 
               MarkOv

------------------------------------------------------------------------
       Mark Overmeer MSc                                MARKOV Solutions
       m...@overmeer.net                          soluti...@overmeer.net
http://Mark.Overmeer.net                   http://solutions.overmeer.net

Reply via email to