Hi, On 22-08-2021 01:18, Antonio Terceiro wrote: > static analysis tools are intended to run on in source code, while > autopkgtest is intended to run against installed packages, where source > code is in principle not relevant; we want to know whether the binary > packages, as provided in the Debian archive, work correctly. > > IMO running this type of tools as integration tests in autopkgtest, or > even as build-time tests is Wrong™, and should not be done. So I would > add another option: For what it's worth, I agree with Antonio both as one of the ci.d.n/autopkgtest maintainers *and* as a member of the Release Team. We don't want failing tests in testing and stable and we don't want allow "regressions" to migrate except for unless needed to solve RC bugs. As an RT member I claim we can always wait until bugs are fixed (or packages removed, see below). > D) report bugs requesting that those packages stop running shellcheck as > autopkgtest. That would indeed be a new variant of the bug reports I regularly file (at RC level, so the offending package typically gets autoremoved). I'll try to remember to add text to this class of "regression" reports that removing the test is the preferred solution to the regression. As these bugs are always RC, they can even be NMU'ed. Paul
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature