On Tue, Dec 9, 2008 at 12:50 PM, Les Mikesell <lesmikesell@xxxxxxxxx> wrote: > It could be as simple as batching updates: suppose everything but critical > security fixes and corrections for known-bad updates only updated every few > weeks, and the user could could choose (with a permanent option) whether any > particular machine should update on the leading or trailing edge of this > window. 1) Couldn't you get most of what you want by having a yum plugin that deliberately held back updates which were too new for your local administration needs? if package build/release datestamps were available in the repository metadata? We already have the security and bugfix flags in the metadata. 2) 'known bad' assumes we actually know that updates are bad before we release them. If we knew they were bad we wouldn't release them at all. > > Or, pick a time frame reasonable both for mirrors to hold updates and for > users to complete testing (2 months?) and only remove packages after their > replacements have reached that age. > > Or, what if one machine's yum automatically acted as a proxy for another's > update, perhaps with an error generated if the package hadn't been > downloaded already and if you want to be even more helpful, a warning if > none of the code from a package had been run on the intermediate machine? Feel free to take over InstantMirror and extend it https://fedorahosted.org/InstantMirror/ -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
