Seth Vidal wrote:
>> On Wed, 2008-11-19 at 11:45 -0500, Seth Vidal wrote:
It ultimately works out to be a mechanism for excluding updates, though.
That's kind of the point. What you call "excluding updates" I call
"Holding the system in a known good state".
My point, however, is that all the bits already exist for excluding
updates.
Whatever criteria or mechanism you want to use to create that list of
excluded pkgs is up to you and completely fine.
Is it possible to give the client most of the control here? That is,
have something like a risk-scoring system where a new update going into
a repo would have a default score of (say) 100 with this dropping over
time to 0 unless new bugzilla entries are made for the package or
someone explicitly bumps it up (or down to push security updates with
little expected new risk). That way engineering ultimately has control
but under most circumstances could let people choose which of their
machines is the bleeding-edge test and which waits for more testing.
The user could then select an acceptable risk level that would exclude
updates with a higher score. The default should probably be to take
everything, but once users had stable systems doing important work, they
could back off and give others a chance to report the problems. Or,
test themselves on a different machine, all working from a common
repository.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
