[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 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: