Re: cvs commit: site/xdocs/dev mirrors.xml

[Aaron Bannert <aa...@clove.org>]

On Wednesday, November 27, 2002, at 09:49  AM, jerenkrantz@apache.org 
wrote:

> jerenkrantz    2002/11/27 09:49:08
>
>   Modified:    docs/dev mirrors.html
>                xdocs/dev mirrors.xml
>   Log:
>   Incorporate some suggestions from the peanut gallery for the mirrors 
> doc.
>
>   Stefan: RedHat->RPM
>   Sander: -current should be a symlink to the symlink in our directory
>   Roy:    historical releases should not be mirrored (said on 
> dev@httpd)

FWIW, I disagree on this last point, for reasons I've pointed out on 
this
and the mirrors@ list in the last few months. Mainly, keeping historical
releases around causes _zero_ additional bandwidth requirements, and 
only
requires a minimal amount of harddrive space, which is not a resource
that should be of any concern to our quality mirrors.

Besides the above points, having our mirrors keep historical releases 
around
gives us benefits -- like automatic offsite backups, as well as quick 
access
to historical references (this happens all the time when we have 
security issues).

As a mirror maintainer, I prefer having old releases.


I'm also willing to reconsider this point if there are actual instances 
of
our mirrors running out of harddrive space. But then again, if this is
just one or two mirrors having this problem, then perhaps they aren't
the kinds of mirrors we want. In other words: Fewer high-quality mirrors
is better than many medium-quality mirrors. I'd rather see 10 official 
mirrors
sync'ing everything than 100 mirrors doing partial sync'ing.

-aaron

Re: cvs commit: site/xdocs/dev mirrors.xml

[jason andrade <ja...@dstc.edu.au>]

On Wed, 27 Nov 2002, Aaron Bannert wrote:

> As a mirror maintainer, I prefer having old releases.

i'll second this point.

> the kinds of mirrors we want. In other words: Fewer high-quality mirrors
> is better than many medium-quality mirrors. I'd rather see 10 official
> mirrors sync'ing everything than 100 mirrors doing partial sync'ing.

ditto.  having a huge number of mirrors is unfortunately only making the
management issue much more difficult and the cost/benefit analysis in
terms of efficiency actually starts falling at a certain point.  in
particular because

o the apache pages are not optimized to make best use of mirrors.  this
  is just going to need a lot of work because this only works well when
  setup this way from scratch.  no criticism implied of people who have
  set it up.

o lots of external places also just point directly at apache.org's
  download area anyway.


regards,

-jason