Re: "Always failed" ? Doesn't seem to be true

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Paul Gevers writes ("Re: "Always failed" ? Doesn't seem to be true"):
> On 20-06-18 12:50, Ian Jackson wrote:
> > I am a bit confused.  I confess don't really understand all this
> > business with `a migration-reference/0 trigger'.  But maybe one should
> > be created if there is no such `migration-reference/0 trigger' rather
> > than if there are no tests ?
> 
> This migration-reference/0 is a hack to avoid needing to run baseline
> tests all the time and basically doubling the amount of tests on
> testing. Britney internally keeps track of the history state of the
> package in testing. If a test passes in testing (but not if it is the
> version of the package itself that is only available in unstable) than
> the baseline state set to PASS. To enable the situation where the
> baseline really goes from PASS to FAIL, brintey treats
> migration-reference/0 special. If it sees that trigger, the baseline is
> updated with that result. The idea is that even without a
> migration-reference/0 trigger seen the internal state would still be
> updated with historical data.

I still find this very confusing.  IMO the test result that should be
considered as a baseline for testing migration of package P is the
most recent test which was
  * of the version of P currently in testing
  * triggered for the migration of P
(Maybe the 2nd condition should be "not a test triggered for the
migration of some package Q != P".)

If britney is keeping its own record of the baseline state, the
baseline state needs to be updated (1) from the new test if the test
is rerun in testing for some reason but also (2) when P_V is migrated
from sid to testing, from the test run of P_V triggered precisely
for that migration.

Does that make sense ?

> That's a feature of urgency high on request of the release team. And
> what's worse for the git case, urgencies are sticky (see also 831699)
> where the urgency of experimental is inherited in unstable. This
> *probably* explains why git gets 2 days now, as the 2 days are NOT
> coming from autopkgtest.

Just read #831699.  What a mess!

Ian.