I think it would make sense to have a bittorrent based FETCHCOMMAND available. The main mirror would run a tracker for the files (is that possible with this many files?) and each mirror would run a "seeder". This would automatically balance the load between mirrors and would add people downloading the files to the mirror list temporarily. Reproducible: Didn't try Steps to Reproduce:
There's no way we could (or, quite frankly, should) force all our mirrors to run a torrent seed, so we'd end up having to track which mirrors did and didn't support torrents. Portage would also have to be modified to support this, the bt client would have to be added to the default system, livecd, etc. and, why? The main advantage of BT is to save bandwidth on the server side and that isn't really a concern for us. Bandwidth isn't a (primary) consideration for us. Basically, I don't see what problem with proposed solution fixes. Other than "bittorrent is cool, so we should use it!!!!!" what does this solution offer? tempted to mark as wontfix, but will leave open for further comment.
Bittorrent is great for distributing large content with a heavy demand. This heavy demand is usually an immediate thing and a (the first week of a release) that would otherwise cause extreme load on an individual server or network pipe. This is the case with our cd releases, however it really is not the case with packages from the portage system (what you are suggesting with the FETCHCOMMAND). The files in the portage system are for the most part, relatively small. The hit to the server and network link is not enough to necessitate P2P. Besides, there are currently 20,525 files in /distfiles/ which would cause a lot of overhead on a BT tracker. Also, this would defeat the source redundancy built into portage if the tracker went down. Going to mark this as wontfix. Cheers
