>>> > problem. The fact that updates default to auto-push after +3 karma is >>> > entirely plucked out of the air, it's just something someone made up >>> > one day. We could *certainly* change that. I'd be quite interested in a >>> > tweak where there's a minimum-time-in-testing value for autopush too, >>> > which would default to say 2 days. The way that would work is automatic >>> > push would never happen until the update had actually been in updates- >>> > testing (not queued for push) for that long. *Manual* push could still >>> > be done during that time, and the update submitter could make the >>> > minimum-time-in-testing value larger or smaller (as they can make the >>> > karma threshold for autopush greater or smaller). 2 days would just be >>> > the default (and is similarly a number I've just made up; we could make >>> > it something else). >>> >>> What if we combined this time threshold with, also, auto-pushes happen >>> only on Monday (or whatever)? >> >> I wouldn't hate it. On a visceral level I've never bought the 'batched >> updates' idea at all, but if it only affects autopushes I don't mind >> tweaking around. It doesn't involve too much work to change, it's easy >> to change back, and manual pushes are still available. > > For whatever reason I've gotten three update notifications in Gnome > Software this week alone, and I've done the restart and install each > time. This is Fedora 25. And then 3-4 times at separate occasions I've > needed to add some command line items and each time dnf does a full > fedora and updates repo metadata download of around 40MB each time, > which is what I thought dnf-makecache.timer was supposed to do in the > background so I'd never see and have to wait for it just to get a 53K > program installed. I actively disable the dnf makecache functionality and just run "dnf --refresh" each time I need to use it as I find the makecache functionality is just broken and pulls down vast amount of data repeatedly. dnf also has an issue where it pulls down all the repo data each tme, the fullfilelist is generally not needed for pure update/package install and yum had functionality where it would only pull that down if and when it was explicitly needed. From memory this is only for things like repoquery against file lists not in the usual bin directories (the bin directory file lists are included in the standard repo data). The full list makes up most of the 40Mb downloaded. The dnf developers seem to think that everyone has lots of data/bandwidth and don't see the problem with it. Peter _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
