Making updates-testing more useful

[Les Mikesell]

Jesse Keating wrote:
> On Wed, 2008-12-10 at 12:54 -0600, Les Mikesell wrote:
>> Could there be a way to throw everything in the same repo and give the 
>> user/installer a choice of how 'well-tested' something should be before 
>> installing it?  Preferably with a sliding scale instead of just 2 
>> choices.  Normally on new installs and machines used explicitly for 
>> testing I'd expect people to want the latest changes but become more 
>> conservative on machines that are working well and used for important 
>> work.  The 'well-tested' concept might have factors for age, feedback, 
>> emergency overrides, etc.
> 
> Take your sliding scale and multiply the various configurations that
> have to be generated/tested by each stop on the scale.

I was hoping this could work independently and unless something is 
replaced with an expedited fix, packages would just age into view.

> Lets say for instance that we want to do a new xulrunner, very raw.
> Every xulrunner dependent app will have to be built for that version and
> included.  Then what if we want to do a new yelp that is pretty well
> tested, but not perfect.  Now we have to build one for the well tested
> scale stop, and keep the other one (what nvrs to use now?!) at the
> untested slot.  Oh for fun, lets throw in something else that yelp
> depends on, but is not in the xulrunner set, that is very well tested
> and stable.  Now you've got a yelp for the very well tested stop, a yelp
> for the medium stop, a yelp with tons of other stuff at the raw stop for
> xulrunner.  What NVRs to apply to these, how many different ways can we
> assemble packages to test for cohesive deps and upgrade paths, and how
> to create a updates system that takes all this into consideration when
> poor fred just wants to update his package?

Perhaps I haven't thought it all the way through, but I'd expect most of 
this to take care of itself via the age factor with the updater ignoring 
anything that doesn't meet the selection criteria on a package or any 
dependencies.  As long as everything works, you'd just be able to get 
the same update the bleeding-edge machines got 2 weeks (or...?) ago. The 
only tricky part would be how to push expedited fixes ahead of the clock 
because they might drag along massive dependencies, but that should only 
be done in rare carefully-consdered cases anyway.  Negative feedback 
could just slow the clock down.

But, feel free to start from scratch on a working design that gives 
control to the end user.  I can't help thinking that a 
version-controlled (git/subversion) package list with tags to give 
snapshots-in-time would be the ultimate way to do it.  That could 
divorce the tool making the 'risk-factor' decisions from yum itself. 
You might build a new set of tags daily, recomputing the package lists 
that should appear in each level of risk and yum would work with the 
list instead of the repo contents.  That would introduce a new workload 
for the mirrors, though.

One other consideration a new package management scheme needs to turn 
this into reproducible updates is to remember the repo where each 
package lives (and understand that you don't know them all ahead of 
time...).


-- 
   Les Mikesell
    lesmikesell at gmail.com