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

Re: How often is any package tested for FTBS on main arch ?

On Fri, 4 May 2012 10:08:44 +0200
Dominique Dumont <dod@debian.org> wrote:

> We, sdl maintainers, made a recent change in our package by removing 
> unnecessary build depends on -dev packages [1].

... at which point you should have looked at the list of reverse
dependencies and done some tests yourselves before uploading ... 

i.e. not rebuild all 400 necessarily but to identify those which of
those 400 do not already build-depend on the packages you removed and at
least let the maintainers of the packages know that your change may
reveal an RC bug in their packages.

There are plenty of tools in Debian which can make such a script

> Unfortunately, some package did rely on this "extra" dependencies and went 
> ftbs [2].

... which could, arguably, be jointly your fault as this could have
been handled cleanly if done so in advance. Yes, the maintainer of the
other packages made a mistake by relying on indirect dependencies (it's
usually best to build-depend on everything you check for in your
configure stage) but that bug was revealed by your change, so it would
have been helpful to raise this as a problem in advance.

> Now is the question of possible impact (FTBS) on all packages build-depending 
> on sdl package (about 400 of them). 
> Hence the question, how often is a given package rebuilt as part of the FTBS 
> tests ? 

Maintainers should not rely on the periodic but not guaranteed FTBFS
checks run by other maintainers in their free time and out of their own
desire for quality assurance. It isn't a *service* to do your work for
you, it is a valuable contribution which should never be taken for

> In other words, knowing that new libsdl1.2-dev package was uploaded on April 
> 10, can we be confident that all potential ftbs were detected ?

No. You do that yourselves, in combination with the relevant
> Given that freeze time in quite close, we are considering to put back the 
> extra build dependencies if too many packages are impacted. We'd then clean up 
> after Wheeze release. 

How about doing the real work instead and identifying which packages
might be affected, alerting those maintainers and starting a few
rebuild tests of this shortened list?  Then you've got some real data
to make the decision about what to do.

Rebuild tests are not restricted only to Lucas, grateful as we all are
for his time in doing them.

Most of us do not routinely rebuild our own packages without some
reason to do so - we may watch on planet.d.o for changes in important
packages, we may read stuff on lists and bug reports but we need to
*know* that there could be a problem and then be given time to make the
necessary upload *before* the breakage is created.

Communication is helpful - causing possibly a few hundred RC bugs is
*not helpful*, whether close to a freeze or not.


Neil Williams

Attachment: pgp18hKrobmIh.pgp
Description: PGP signature

Reply to: