On 13710 March 1977, Christoph Anton Mitterer wrote: >> I'm not sure going below a dinstall cycle is useful. Probably even two. >> Have it expire before the new stuff even got a chance to get out is not >> a good idea, IMO. > Are there any numbers how long it actually takes for the stuff to get > distributed? Maybe somewhere, dont know. > Anyway, even if there are technical issues, don't you think that it > sounds kinda stupid, if all the distros and security guys try to > orchestrate the publication of important issues (like the apt or bash > stuff we've seen these days), so that basically fixed packages could be > available for all distros at nearly the same time, while we still leave > our users basically vulnerable by having far too long validity times. It also sounds quite stupid that suddenly all users have no working mirror anymore, should there be an outage of ftp-master or security-master longer than the signing time. Or a release going on, during which we commonly turn off the archive and ALL cronjobs. Until we are sure that it is all fine again. No, a full release doesn't go through in less than a dinstalls time. Even down to two dinstall intervals is short and would require us to add one more level of complexity to our working. >> That is technically not a big problem. Unless you happen to look at >> services like snapshot, which run an import on every trigger. No idea >> how much it hurts them if only the Release files change, need to find out. > Well I think snapshot is it's own construction site, isn't it? > IIRC, snapshot ships the old Release files, and thus everything older > than a few weeks is anyway considered invalid, right? > And doesn't it also use the old GPG keys? I don't care here what snapshot ships. Wrong point to look at. It's import runs are costly, and it gets ALL of the mirror runs. -- bye, Joerg <liw> er, *not* what I meant, is what I meant
Attachment:
signature.asc
Description: PGP signature