Hi Ian,
On 20-06-18 16:40, Ian Jackson wrote:
> 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
But this is normally tested with something from unstable that MAY have
caused a regression. Everything after that would be allowed to ALSO
regress the package without getting the additional age. Therefore one
would need something that triggers testing in testing, but not for every
test (that would duplicate everything).
> * triggered for the migration of P
Unfortunately, britney doesn't really keep track of that. This would
have been the preferred solution. I don't know how to achieve this easily.
> (Maybe the 2nd condition should be "not a test triggered for the
> migration of some package Q != P".)
But britney doesn't keep track of past migrations. So I come back to the
migration-reference/0 trigger. This can be triggered externally until we
teach britney how to do it properly itself.
> 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 ?
As argued, no for (1), and difficult for (2) in the current code base.
>> 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!
My IRC comment noting this bug triggered action. So maybe...
Paul
Attachment:
signature.asc
Description: OpenPGP digital signature