F11 Proposal: Stabilization

[Les Mikesell]

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 at gmail.com