On Fri, Jan 13, 2017 at 07:35:10PM +0000, Simon McVittie wrote: > On Fri, 13 Jan 2017 at 18:22:53 +0000, Ian Jackson wrote: > > Maybe an intermediate position would be to respond to a CI failure by: > > * Increasing the migration delay for the affecting package > > * Notifying the affected package maintainers > > I think this makes sense: it gives the maintainer and other interested > developers some time to assess whether the failure is a showstopper > (=> upload a fix/revert/workaround, or at worst file a RC bug) or not. > > Or, conversely, blocking migrations but letting the relevant maintainers > remove that block might work.
Agreed (if any of this is practical in britney). > On Fri, 13 Jan 2017 at 13:54:26 -0500, Scott Kitterman wrote: > > Probably the simplest way to avoid problems with systems like this is to > > remove any autopkg tests your packages are shipping. > [...] > > P.S. Perverse incentives FTW. > > This is my concern too. If you maintain a useful package with tests that > are unstable but do not imply a release-critical issue, running those > tests and recording-but-ignoring the failures seems considerably better > for Debian than either disabling the tests or removing the software > (more information is better than less information, and if the package > is useful despite the test failure then it's better to have it than not). > > Possible autopkgtest extension: "Restrictions: unreliable"? May as well just use "Restrictions: allow-stderr" and "... || true". That's easier to do on a more fine-grained level, too. -- Colin Watson [cjwat...@debian.org]
