> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > >> On 01/08/2018 10:53 AM, Kevin Kofler wrote: >> Kevin Fenzi wrote: >>> Well, if this firefox update was urgent, shouldn't it have been marked >>> urgent? >> >> Urgency is always in the eye of the beholder. I as a user consider all >> security updates "urgent", and in addition, I want ALL updates as soon as >> they passed testing no matter whether they actually are urgent. > > You also don't want updates-testing to even exist right? > >> >>>> I really don't understand why we do this "batched" thing to begin with. >>> >>> To reduce the constant flow of updates that are very minor or affect >>> very few mixed in with the major updates that affect lots of people and >>> are urgent. >> >> But the users were already able to opt to update only weekly. So why force a >> fixed schedule on them? > > To save all the Fedora users in the world from having to update metadata > for minor changes. Since there's a hourly dnf makecache every user in > the world pulls down new metadata ever time we update a repo. Could Fedora, perhaps, come up with a way to make incremental metadata updates fast? This shouldn't be particularly hard -- a tool like casync or even svn should work pretty well. Or it could be a simple ad-hoc thing. Have the mirrors serve up both the whole metadata blob and a list of metadata changes. The client could grab the list of changes from last time, compute a bitwise-identical blob, and verify the signature on that, deltarpm style. (But on the decompressed data, of course -- no need to repeat the mistakes of the past.) It seems that all this batched stuff is a rather weak hack to work around the extreme inefficiency of Fedora's metadata distribution model. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
