F11 Proposal: Stabilization
Les Mikesell
lesmikesell at gmail.com
Wed Nov 19 22:24:09 UTC 2008
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
More information about the fedora-devel-list
mailing list