On Jan 9, 2018, at 9:59 AM, Kevin Fenzi <kevin(a)scrye.com>
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.