[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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                                       [cjwatson@debian.org]

Reply to: