On 10/02/2023 06:41, Andreas Tille wrote:
Am Fri, Feb 10, 2023 at 08:44:01AM +0530 schrieb Nilesh Patra:
But I am not sure if this counter would be set to 2 days (from 5 days)
or not -- will likely need to ask release team.
As far as I observed the migration time is now 5 days (no matter whether
autopkgtest or not).
I think the "5 days" on the tracker page is because the reverse
dependencies' autopkgtests haven't all been run yet, and will change to
2 days once they have:
https://release.debian.org/testing/freeze_policy.html
On 10/02/2023 03:43, Diane Trout wrote:
> Though I made two changes that should dramatically increase the odds of
> the tests passing.
>
> One I told it to skip all the "isinstalled" marked tests, which are all
> skipped during build time, and the build seems to run far more
> reliably.
>
> I got the idea because it seemed like the vast majority of test
> failures are related to the daemons running or failing to shut down.
That might be true on amd64, but I don't think it's true of arm*/s390x:
the tests that are failing there do *not* appear to be isinstalled tests.
I suspect the tests wouldn't have worked on those architectures in
2022.02 either, and we didn't notice because the previously mentioned
bug was causing the autopkgtest to not actually run the tests.
(dask.distributed is arch:all, so it's only built once, presumably on
amd64.)
> While talking on IRC about dask.distributed problems I learned of the
> flaky autopkgtest restriction which says the test is expected to fail
> intermittently and is not suitable for gating continuous integratin.
>
> So I marked the current whole autopkgtest run as flaky.
>
> So CI should also ignore the results of failed test runs now.
Having only flaky tests that fail counts as having no tests:
https://sources.debian.org/src/autopkgtest/5.28/doc/README.package-tests.rst/#L230
That presumably means 5 days, which we don't have, i.e. *don't* unless
release team tell you otherwise.
> When under less time pressure I think a good plan might be two split
> the tests internally marked as isinstalled or flaky into a separate
> autopkgtest run that's marked flaky and let the CI gate on the more
> reliable tests.
As stated above, that's probably the wrong split for this.
