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.
>> 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 users downloads of repodata.
This does not work in practice because there is almost always at least one
urgent update that requires downloading the whole repodata. (And also
because maintainers are free to skip batched without giving a reason. I
always do this because I consider batching a disservice to my users.)
> rel-eng's schedule is a cron job at 03:00 on tuesday (so the batch
> appears on wed's pushes).
>
> There was some discussion about changing the gnome batching based on the
> Fedora batching, but I don't know whats happened there.
But what if this is a company that wants to do weekly updates on Monday
morning in order to be free from disruptions for the working week? Then they
will get the updates up to almost 2 weeks late rather than up to 1 week as
both you and they intend.
Batching really needs to be left to the client side!
> I haven't seen a bunch of urgent updates get blocked by this process.
> Do you have more data for updates that hit this?
I have empirically seen security updates end up in the batches, but I have
not checked each of them to see whether it actually went through "batched"
or just happened to go out on that day.
But again, I think it is essential for users to be able to opt to getting
updates without arbitrary delays.
>> If people insist on that "batched" misfeature, can we please at least get
>> a fast track repository that contains all the batched updates (but no
>> updates that are still in testing and have not been batched yet!)?
>
> I would be very much against additional repos like this.
Why? It would allow you to keep the server-side batching while still
allowing those users like me to opt out of it. And the repodata download
size for fast track would be minimal if updates that went out to stable get
removed from fast track.
Even RHEL has a fast track repository.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
