F11 Proposal: Stabilization

[Les Mikesell]

James Antill wrote:
> 
>>> 1. Too many people want to be consumers of the testing but not the
>>> providers of it.
>> I think that's an unwarranted assumption.  How many people even know 
>> about updates-testing compared to people that never change defaults? 
> 
>  Certainly everyone in this thread knows about it.

So maybe a dozen people...

>> How does someone using updates-testing ensure that their usage 
>> 'provides' something?
> 
>  bodhi -k +1 -c 'pkg FOO, works for me'
> 
> ...or even just leave the comment.

That's (a) not something many people are likely to do, and (b) not quite 
what I want to know.  I want to know that the combination of packages 
installed on machine X at time Y worked together correctly (including 
the kernel and base libs that may affect but not be specifically tied to 
the package in question) before I install that same set on machine Z at 
time Y + something.

>>>  Indeed IMO the whole updates-tested argument seems to devolve to "I'm
>>> going to be clever and switch to this, but I'm pretty sure a bunch of
>>> other people aren't going to know immediately and so will become my
>>> unwilling testers".
>> No, the argument is this:
>> If I had a way to be moderately sure that my main work machine would be 
>> usable every day running fedora and I could test things on a less 
>> important machine, I'd be much more likely to run fedora more of the 
>> time and on more machines.
> 
>  So subscribe your work machine to just updates, and your test machine
> to updates-testing ... what is the problem here?

Is the flow exactly predictable?  That is, can I know that the package 
set I get from updates will correspond exactly to what I tested earlier? 
What is the process for problems detected in testing?

>>> 2. The people who are the providers of the testing, aren't necessarily
>>> running the same kinds of workloads as the people who want to just be
>>> consumers of the testing.
>> Exactly - it doesn't work that well as is.  And even if I wanted to test 
>> exactly the same work on exactly the same kind of machine, I don't think 
>> I could predictably 'consume' that testing value - that is, there is no 
>> way for me to know when or if a 'yum update' on my production machine is 
>> going to reproduce exactly the software installed on my test machine. 
>> (Personally I think this is a generic yum problem and it should provide 
>> an option for reproducible installs regardless of what is going on in 
>> the repositories, but that's a slightly different issue...).
> 
>  Sure, it's one of the many things on the TODO list to fix ... and with
> yum-debug-dump / yum shell / etc. there are a couple of ways of hacking
> this kind of thing in.
>  However if you were running updates-testing refreshes fairly often then
> anything going into updates would be fine for you, by definition.

Are sets of updates moved atomically from one repo to the next, holding 
back the whole set for a problem in one package, or will I really get an 
unpredictable grouping out of updates?

-- 
   Les Mikesell
    lesmikesell at gmail.com