>> Well, in fact, given the way tcp work, I do not see how it could
>> suffer from a transmission problem.
Tcp corrects errors with a certain likelyhood. I do not know what
CRC-something is used by ftp - for CRC-16, depending on the type of
error and the package length, probablilities are smaller than 10 power
-6 (I did these figures many years back, rapid googling does not provide
any evident figures). Anyhow, with this order of magnitude, and with the
100 M bytes(!) of a typical largish package, the probability of
receiving an apparently good package which after all is not so good is
non-negligeable. Doing another check at the application level therefore
may be of substantial merit. Would be good to get input from somebody
who is more competent.
>>I think the instruction for now are only for cauldron
That is what I thought. "Production mirrors" like Switch may be
reluctant to deviate from their ordinary schedule of 24 hours.
I think that the request should be formulated in a subtle way: avoid
that a reject on cauldron terms implies a reject for production mirror
requirements - and a mirror for the stable release is the essential
issue, the stable release Mageia should be present at all major mirror,
that is the priority (cauldron could probably live with a reduced number
of mirrors). But the present pre-release of Mageia is a special case:
there exists no stable alternative, and the initial pre-releases have a
vital interest of being easily accessible. But I am doing what should
not be done: risk to create a problem by talking about it (-
Juergen
