[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OSSTEST PATCH v2 08/41] sg-report-flight: Ask the db for flights of interest

  • To: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • From: Ian Jackson <ian.jackson@xxxxxxxxxx>
  • Date: Fri, 31 Jul 2020 16:43:42 +0100
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 31 Jul 2020 15:44:00 +0000
  • Ironport-sdr: wPtrGNpzJe90TRtXKcvePH2T7zpctB+mpZoXOMyU4AgL7niD4giJ6WlNMjpUbkHL7R+5Qw/c/Y nbeUnsUt9DlufPzjPLDhogIJ6vHta/VrWKX+Kgq3o51HoAe+BRNX/aiHu22/jbC21xbUoAVtjC H24FS1bhKInRDIHEHpdPT3o1NSVzB+AmpsvrN1F2pvjx8cqoWaozm0q5EKyJyJL9prLaMF6qrK urpWk/iEIJLSWS5ZVC0jFp1s2r9tdaIL32h3JinuPVyioIMqeBApZDJxU/feSC3jc3ZHzDuKAA Vec=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.jackson@xxxxxxxxxxxxx> 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.dunlap@xxxxxxxxxx>


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




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.