Comment 3 for bug 913235

yes - mirrorbrain is an apache module, the individual mirrors still would get the stuff via rsync, mirrorbrain is not involved in that part. All mirrors can be used individually as they are now. So when you got a server that can run apache & has the mirrored files, you got all it needs to set it up.

The only thing that needs to change woul be that the "mirrorlist" method would only return one single URL, namely the mirrorbrain one. (or if you want to play ultra, ultra safe, just provide the mirrorbrain url as additional mirror and advertise it on the webpage/forum/blogs instead of "forcing" it on users as an initial step, and do the switch of the mirrorlist method when you gained confidence in it)

LibreOffice as well as OpenOffice.org before for example also use mirrorbrain.

You got one single URL per download:

http://download.documentfoundation.org/libreoffice/old/3.4.4.1/mac/ppc/LibO_3.4.4rc1_MacOS_PPC_install_en-US.dmg

but depending on where the access is done from, the user will be redirected to the actual mirror. You can append a ".mirrorlist" to see what choice it did make, and what alternative mirrors you could use (as well as md5, sha1sum and some additional stuff)

http://download.documentfoundation.org/libreoffice/old/3.4.4.1/mac/ppc/LibO_3.4.4rc1_MacOS_PPC_install_en-US.dmg.mirrorlist

(SuSE also uses it for its mirroring btw)

For users who already have a manual mirror configured, nothing will change, this is still possible.

Mirrorbrain won't interfere with the distribution of files to the mirrors and won't remove the option to manually specify a mirror. You can do a smooth transition as described above (set it up and advertise mirrorbrain as experimental method, i.e. invite users to change their media sources to the mirrorbrain URL, and after some time change the mirrorlist definition to only include the mirrorbrain URL), but it really doesn't demand much ressources/you don't need to be afraid of it generating too much load.