George Dunlap writes ("Re: [OSSTEST PATCH v2 08/41] sg-report-flight: Ask the
db for flights of interest"):
> > On Jul 31, 2020, at 12:37 PM, Ian Jackson <ian.jack...@eu.citrix.com> wrote:
> > Specifically, we narrow the initial query to flights which have at
> > least some job with the built_revision_foo we are looking for.
> >
> > This condition is strictly broader than that implemented inside the
> > flight search loop, so there is no functional change.
>
> Assuming this is true, that job / runvar is filtered after extracting this
> information, then...
...
> …I agree that this shoud introduce no other changes.
>
> Reviewed-by: George Dunlap <george.dun...@citrix.com>
Thanks.
Just to convince myself, I ran through the argument based on the perl
code. I found a lacuna.
1. The job of findaflight is to find a flight, and it doesn't have
significant side effects - just a return value.
2. If it returns a flight from the loop, $whynot must have been
undef. $whynot is never unset.
Consider some tree in %{ $specver{$thisthat} }.
3. If @revisions is 0 for that tree, $whynot is set. So one of the
two queries $revisionsq or $revisionsosstestq must have returned
some rows.
4. Furthermore, none of those rows must have passed the $wronginfo
grep. If they had, $whynot would have been set. Any row
whose val doesn't contain a colon, and which doesn't end up
in $wronginfo, had a val equal to the requested specver.
5. Colons in this field appear only in mercurial revisions. These are
now obsoelete - we have no mercurial trees. A consequence of this
commit is actually that we should explicitly abolish mercurial
support, at least pending a change to osstest to arrange for the
val column to contain only the hash part and not the number part.
6. Together, these conditons means that if $whynot wasn't set,
there must have been some row whose val matched the specver.
7. Both the $revisionsq and $revisionsosstestq queries take a flight
bound variable condition. This is bound by a value that came out
of @binfos. @binfos is made from %binfos, where the flight number
is the key. %binfos is populated by the @binfos_todo loop, where
it gets the flight number from a @binfos_todos entry - but it
filters them for $bflight == $tflight.
8. So some row must have matched the flight, and the specver, and
of course the name. This is precisely the new condition.
I think this means I should put a commit earlier in this series which
disables mercurial support until the colon version situation is
rationalised.
Ian.
