Well, trying other mirrors as well would be a nice to have, but I don’t know if that’s always such a good idea. If there is a checksum error, you would have to find out whether it’s an issue of the metadata or the file. So you would have to start downloading the metadata from all mirrors and figure out whether there is newer metadata somewhere. If it’s the same everywhere you would have to download the rpm/iso from all mirrors to see if you find it somewhere matching the checksum of the metadata. If it’s a larger file, e.g. the boot.iso, you might start downloading several gigabytes worth of files all in vain because possibly it’s not an issue of metadata not matching the files but it’s actually “broken” upstream…
I guess checking other mirrors might be possible if a file is missing on one mirror. But even then, again, you have to check validate the metadata of the other mirror as well because possibly, the file missing is supposed to disapppear but the local metadata is not yet updated…
My reference is simply what I would see if I use the mirror/upstream repos directly. I won’t see any issue, no incorrect checksums, missing files or missing dependencies as long as I don’t use them.
I don’t know the exact statistics but let’s say the average server is using only 1% of all rpms/files in a repository. If there is a checksum error somewhere between the repo metadata and a file on a mirror, chance is very slim that I am affected. If there is a dependency issue, e.g. a dependency is missing on the mirror because it hasn’t fully mirrored, yet, changes are slim I would even notice. So my guess would be that most issue I would never notice, if I used the mirrors directly. But still, I get timely updates. And if there is a problem, I can try other mirrors or simply try a day later.
What I don’t find very useful is aborting the sync the moment you find a single issue between the metadata and the packages/files. It affects one or maybe a few files in the repository but still almost everything in the repository is correct and could be synced… I don’t see a good reason why the pulp sync should try to create a repository view which is more stringent than the upstream repository.