Testing Fedora - small (?) suggestion.

[Adam Jackson]

Jesse Keating wrote:
> On Saturday 11 November 2006 13:26, Nicolas Mailhot wrote:
>> Not if we block only the broken parts. You know, instead of using
>> testers to shame maintainers in fixing broken deps, have the buildsys do
>> it, and only expose sane trees to users (with the "broken" packagesets
>> being held where the buildsys can find them till they're complete)
> 
> Thats quite the complexity to try spinning the tree, find broken deps, drop 
> out packages, try again, rather, rinse repeat.

No, it's a do-while loop.

If you start doing this from a working tree, you always have yesterday's 
known-good state to start from.  On any given day, some subset of your 
packages will have changed EVR.  Start with a compose that includes all 
updated packages, and walk it for broken deps.  Define depgraph 
subtrees, rooted at and containing only components in a broken dep line 
(both sides) that have been updated since yesterday.  Prune them from 
the candidate set for compose, and try again.

Brief gedanken analysis tells me this is roughly O(n log m) on worst 
case behaviour, where one is the number of subtrees and the other is the 
number of updated packages.  I suspect in practice we'll see a typical 
running time of 2.

This does mean there will be a set of packages in a new limbo state, 
where they're built and published but not yet in a compose.  Those 
packages simply go into the candidate set again in tomorrow's compose.

Also the "both sides" part above might be aggressive, if we had done 
that for the rawhide leading to FC6 then the kernel would never have 
been updated because gnbd was always broken.  Tough.  Fix it, either by 
excluding broken crap from the compose, or - shock - fixing the broken 
packages.

(Jesse, I suspect the model you're thinking of it "oh crap, the tree has 
broken deps, we can't publish _anything_".  Which is wrong.  You publish 
the bits that are at least guaranteed by RPM requirements to install.  I 
mean, you want that for the updates stream for formal releases anyway, 
where 'yum update' should _never_ fail, and I suspect right now the 
releng team is doing that verification by hand.  Trust the computer. 
Let it do the boring work.)

> Look, rawhide is just a work in progress, a snapshot of what happened the day 
> before.  We can't aways have a completely stable tree.  Trying for that is 
> the road to insanity.

Look, the kernel is just a work in progress, a snapshot of what happened 
the day before.  We can't always have something that compiles.  Trying 
for that is the road to insanity.

Let's play spot the fallacy!  Hint: only one sentence was wrong.

Standard practice for rapid development environments is to require 
working daily builds.  For a distribution, an installable package set is 
the definition of working.

- ajax