On Wed, Jan 10, 2018 at 2:23 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: >> 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. This was actually prototyped two years ago with zsync: https://github.com/rh-lab-q/deltametadata-prototype It worked, but it was slow since it wasn't implemented in librepo and of course we never got it implemented in the infrastructure. Details: https://github.com/rh-lab-q/deltametadata-prototype/wiki/Deltametadata-of-repo-md-files The Plan of 2017 that never got done: https://github.com/rh-lab-q/deltametadata-prototype/wiki/Plan-2017 -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
