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

[Neil Williams]

On Fri, 4 May 2012 10:08:44 +0200
Dominique Dumont <dod at 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
possible.

> 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
granted. 

> 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
maintainers.
 
> 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
=============
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-sdl-maintainers/attachments/20120504/1128b24f/attachment.pgp>