> > 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.)
Ok yes there could also be issues with their serialization code on unusual architectures. > > 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. It might not be enough to solve all dask.distributed's test problems, (as you point out for the other architectures) but it does seem like their test suites include both unit tests that don't depend on the host networking, and integration tests that are strongly impacted by the configuration of test runner. And there might be value in separating the unit & integration test types?
