Bill Nottingham wrote:
You've run a public mirror for 10 years. It's simple. Now, we come along and say "oh, if you actually want to conserve your bandwidth locally, you're going to need to set up separate ACLs and filters that allow your content to be visible from your IP range but not publically". You're essentially telling our mirrors how to run their mirror for their site.
They can it run however they want. If they want to conserve their bandwidth what I am providing is a suggestion on how to handle that problem while serving their local users since this was projected as a problem. I don't know whether mirror administrators have actually complained about this or whether we assume they will.
And for what gain? So some people can get a release a couple of days early?
Yes. The project benefit is that we split the load. Some folks who prefer and can use the torrent will get it early. The rest will get it 4 days later. It has nothing to do with bragging rights or filing bug reports although I don't see a problem with either of that.
We have end users wondering why we are holding back on the release after the images are ready instead of making it available on the bittorrent and the answer seems to revolve around not affecting the perceptions of mirror administrators that somehow their path is treated as second class which as a end user seems rather weak to me. If I was a mirror administrator I would be very happy if the bandwidth was used less and the load shared by other folks running mirrors, torrent or anything like that.
My original problem description had nothing to do with making the torrent go faster BTW. That would be useful indeed and what has been planned would work for that. No oppositions.
Rahul -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
