Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Monday, January 16, 2017 01:06:19 PM Martin Pitt wrote:
> Hello all,
>
> Scott Kitterman [Fri, 13 Jan 2017 13:54:26 -0500]
>
> > 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.
>
> No, that won't work at all. If you upload libfoo which regresses a reverse
> dependency bar and bar's tests now fail, then removing libfoo's autopkgtests
> won't help you *at all* in landing the new libfoo in testing. You'd need to
> convince bar's maintainer to change/drop the test.
>
> The carrot for adding tests is that the better they are, the harder you make
> it for *other people* (i. e. your dependencies) to break your software. The
> stick is that you then of course need to make/keep your own tests running
> so that you can upload new versions of libfoo yourself.
>
> So IMHO the incentives are quite right here.
Of course if we just never allow anything into Testing, there's no risk of bad
software migrating.
This is going to take a lot of work. I see random failures routinely block
migrations in Ubuntu (postfix is a current example - there's two alleged
regressions that to the extent they are valid are completely unrelated to
anything that changed in the package).
The question is who's going to do the work? I don't see the release team
having tons of spare cycles to dive into the details of individual test
results and package failures and decide what's RC and what's not. The only
thing that scales to something the size of the Debian archive is to let the
maintainers decide.
Yes, some of them will abuse that authority, but that's true of anything.
Scott K
Reply to: