On 10 January 2018 at 14:23, 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 This sounds a lot like the Atomic project and how it does things... > 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. All things are a weak hack to work around some inefficiency and an extremely important process to deal with needs. Trying to label something without taking into consideration of the other is where most arguments go pear shaped. > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
