Re: Trimming the CPAN - Automatic Purging
Hi Elaine, Elaine Ashton wrote: On Mar 28, 2010, at 12:48 PM, Randy Kobes wrote: Jarkko and I were talking about it this morning - as he's not in favour of pruning - while trying to think of a way around the size problem and he reminded me of the idea that, if I recall correctly was Adreas' suggestion a while back, there be an A, B and C 'PAN' of sorts where you could pull varying degrees of content - sort of CPAN:Mini writ large. I don't think that idea ever got any traction because it wouldn't really solve some of the issues for the major upstream mirrors and the mechanics of deciding where to draw the lines between them. I still think it's a good idea though. This sounds a bit like the CPAN - backpan scheme but with some additional levels? I do very much like Tim's proposal for giving old modules a push to BackPAN since, with proper communication of the changes to the authors along with a way to mark exceptions, this would rid CPAN of a lot of cruft that should be on BackPan anyway. I'm not even going to throw in my considerable weight on this whole debate of pruning*. But if backpan became the official way to access old versions starting from yesterday's, wouldn't that mean: a) That the toolchain would have to be adapted to a tiered infrastructure (think of the indexes...) and more importantly: b) The backpan would have to be mirrored all over the place as well, thus pushing the problem to the next level? Best regards, Steffen * If you must know, I don't like the means but sympathize with the goals. PS: This isn't targeted at Elaine specifically, but can everybody please take a step back and relax? Please be civil.
Re: Trimming the CPAN - Automatic Purging
On Sun, 28 Mar 2010, Andy Armstrong wrote: We're nearly there if A == a CPAN::Mini style mirror, B == the current mirror pruned and C == backpan. So the actions to make that happen are: * give the current clients specific support for this * generate a master mini mirror that other mini mirrors can pull from. * prune If we agree that this is a good solution I'm happy to do some work on it - I could host the mini master and I'd be happy to send Andreas a patch for CPAN.pm to support this scheme. It should be pointed out that this is only viable under the assumption that you have a separate pool of servers for each tier. Again, this is just load balancing, not load optimization. That said, if you have the volunteers, then why not. Perhaps I can offer a system to support mirroring up here in Alaska. --Arthur Corliss Live Free or Die
Re: Trimming the CPAN - Automatic Purging
On Sat, Mar 27, 2010 at 09:38:16PM -0400, Elaine Ashton wrote: I suppose I don't understand the opposition to trimming off the obvious cruft on CPAN to lighten the load when BackPAN exists to archive them. There is already CPAN::Mini (which was created back when CPAN was an ever-so-tiny 1.2GB) so it's not as though lightening the load is a new idea or an unwelcome one. My understanding is that CPAN::Mini is aimed more at end-users who want to have CPAN-onna-(memory)-stick or on a laptop. Back in 2004, dedicating 1.2GB of laptop space was rather more significant than it is now - my laptop at the time had something like 30GB, and that had to include the OS and all my mp3s. A CPAN-onna-stick was very useful at hackathons and on train journeys. -- David Cantrell | Official London Perl Mongers Bad Influence I think the most difficult moment that anyone could face is seeing their domestic servants, whether maid or drivers, run away -- Abdul Rahman Al-Sheikh, writing at http://www.arabnews.com/?article=38558
