Hi,

Ciaran McCreesh <ciaran.mccreesh@...>:

> On Mon, 9 Mar 2009 23:20:03 +0100
> Christian Faulhammer <fauli@g.o> wrote:
> >  Package A goes stable, test suite passes.  Package B (a dependency
> > of A) goes stable in a newer version, which will cause A to not
> > merge in stable profile.  This happens all the time and is no
> > special case.
> 
> Uh, you *are* testing things that use a library before you stable that
> library, right?

 When I was an architecture developer I tried to.  But when stabilising
a minor version of curl (for example), testing all reverse dependencies
is no option.  But this broke tests for Bazaar for example in stable.
 Or another issue.  Badly written Autoconf systems which will break in
src_test() with a different version of intltool, which is not a direct
dependency.  That pitfall hit me several times in the last years.
 The more, x86 e.g. ranges from embedded Geode platforms to dual core
desktop systems and running the sqlite test suite on the first is no
fun.  As a user I would not accept two hours of build time.
 Test-driven development is great, but not so widely used as one could
wish it to be.

> Besides, if a newer version of a library breaks a package using it,
> you most definitely want to know about it before you end up merging
> something that won't work. If src_test is failing where it used to
> work, it's a very good sign that something's broken, and you shouldn't
> be carrying on.

 Arch devs run test suites and won't stabilise if it fails (except some
special cases).

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>