Hi Graham, On Mon, 03 Jul 2017 15:35:00 +0000 Niels Thykier <niels@thykier.net> wrote: > The status quo is that: > > * A failure can be RC if it basically shows that the package is broken > or have significantly regressed in functionality (possibly caused by > a dependency). > > * But autopkgtests failures in themselves are not RC at the moment. Do you still consider this the status quo? Currently we are filing bug reports when there is regression in testing, we are finding serious issues, but unfortunately we can't always figure out in a reasonable time how broken the package actually is. As we want to move to the blocking state soon (once we have improved britney to calculate the set of packages from unstable that are needed to test, such that we can disable the apt-get fallback in autopkgtest; code ready, testing ongoing) wouldn't it be reasonable to file the bugs we are filing against both packages (the triggering one and the failing one) at a higher level? Of course with the clear explanation that if the maintainers consider the issue to be non-critical they shouldn't hesitate to lower it? > * Analyse autopkgtests failures and file bugs as appropriate (RC when > the package appears to be actually broken, non-RC otherwise). > - Patches are probably very welcome here as well. We are doing that, but as I mentioned above, often it isn't easy for a bystander to judge and so far I have been reluctant to do this at higher than normal severity unless I was really convinced the autopkgtest showed complete broken packages. This is the list of failures we have spotted the last couple of months (some were filed before by Adrian Bunk due to FTBFS on reproducible-builds): https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-ci@lists.debian.org Paul
Attachment:
signature.asc
Description: OpenPGP digital signature