On Fri, Apr 2, 2010 at 4:11 AM, Michael G Schwern wrote:
>> * The need for widespread mirroring is less significant than it was in
>> years past. (Also using git as the inter-mirror transport of source files
>> means there'll be much less traffic between mirrors. Effectively only
>> the diffs betw
On Fri, 2 Apr 2010, Ask Bj?rn Hansen wrote:
Talk = ZzZz.
Code = Interesting.
Deployment = Useful.
Please. The talk serves to gauge interest before I waste any time
implementing a solution that's already been rejected out of hand. As I've
mentioned repeatedly I already use rsync, albeit on mu
On Fri, 2 Apr 2010, Ask Bj?rn Hansen wrote:
I can't believe I'm doing this, but ...
:-) All for entertainment's sake...
The main point here is that we can't use 20 inodes per distribution. It's Just
Nuts. Sure, it's only something like 400k files/inodes now - but at the rate
it's going
On Thu, Apr 1, 2010 at 7:50 AM, Tim Bunce wrote:
> On Thu, Apr 01, 2010 at 12:39:27AM -0400, David Nicol wrote:
>> On Wed, Mar 31, 2010 at 7:43 AM, Ask Bjørn Hansen wrote:
>> > The main point here is that we can't use 20 inodes per distribution.
>>
>> so don't. How much reengineering would be nee
Much of this discussion is beyond my depth but in terms of keeping it
simple, and trying to limit the stat calls on the upstream servers,
what about DNS as a replication model? You could break up the tree at
logical divisions similar to zones and assign them serial numbers
(say a .serial file) and
On Thursday 01 April 2010 05:39:27 David Nicol wrote:
> On Wed, Mar 31, 2010 at 7:43 AM, Ask Bjørn Hansen wrote:
> > The main point here is that we can't use 20 inodes per distribution.
>
> so don't. How much reengineering would be needed to keep CPAN in a
> database instead of a file system?
It
On Apr 1, 2010, at 16:50, Tim Bunce wrote:
> * The need for widespread mirroring is less significant than it was in
> years past. (Also using git as the inter-mirror transport of source files
> means there'll be much less traffic between mirrors. Effectively only
> the diffs between releases.)
T
On Apr 1, 2010, at 19:49, Arthur Corliss wrote:
I can't believe I'm doing this, but ...
>> The main point here is that we can't use 20 inodes per distribution. It's
>> Just Nuts. Sure, it's only something like 400k files/inodes now - but at
>> the rate it's going it'll be a lot more soon en
On Apr 1, 2010, at 19:49, Arthur Corliss wrote:
> I've made a viable suggestion, and offered some time to work on it. But
> you've made it abundantly clear that it's not welcome.
Talk = ZzZz.
Code = Interesting.
Deployment = Useful.
- ask
On Apr 1, 2010, at 1:12 PM, Tim Bunce wrote:
> Yes, I was envisaging something like gitPAN. Though if this took off
> then moving the tarball->git import logic to the PAUSE server would
> probably be a good idea.
/me stashes these ideas away for PGAN…
On Thu, Apr 01, 2010 at 08:03:53PM +0300, Burak Gürsoy wrote:
> > From: Tim Bunce [mailto:tim.bu...@gmail.com] On Behalf Of Tim Bunce
> > Subject: Distributing the CPAN
>
> > * cpanminus already supports installing from a git repo.
>
> > * Over time the number of cpan-git-mirror's and cpan-git-se
On Thu, 1 Apr 2010, Tim Bunce wrote:
Random thoughts...
* If you squint a little you can view git as a database with excellent
replication support.
* cpanminus already supports installing from a git repo.
* For backwards compatibility a simple perl web server could provide a
classic CPAN http
On Wed, 31 Mar 2010, Ask Bj?rn Hansen wrote:
Everyone who doesn't run mirrors says "oh, who cares - it doesn't bother me".
Some of us who does run mirrors say "actually, that sort of thing is important and
an actual issue.".
Others reply "then you're doing it wrong". But nobody came with
On Thu, Apr 01, 2010 at 03:50:49PM +0100, Tim Bunce wrote:
> * The need for widespread mirroring is less significant than it was in
> years past. (Also using git as the inter-mirror transport of source files
> means there'll be much less traffic between mirrors. Effectively only
> the diffs betwee
On Thu, Apr 01, 2010 at 12:39:27AM -0400, David Nicol wrote:
> On Wed, Mar 31, 2010 at 7:43 AM, Ask Bjørn Hansen wrote:
> > The main point here is that we can't use 20 inodes per distribution.
>
> so don't. How much reengineering would be needed to keep CPAN in a
> database instead of a file syst
15 matches
Mail list logo
