gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <ru...@apache.org>
Subject Re: [RT] a strategy for better gump action/reaction analysis
Date Fri, 13 Aug 2004 22:08:08 GMT
Stefano Mazzocchi wrote:

> Both projects compiled yesterday. We have artifacts from both in the 
> archive.

If you can do "cvs update -D", you don't need artifacts.  I used to 
routinely be able to isolate the individual commit that caused a given 
failure by one by one rolling back projects, until the failure went 
away, and then doing a binomial search over the time range to isolate 
the individual commit.

> If A builds but B doesn't, there are two possibilies:
> 
>  1) B broke itself
>  2) A broke B

A breaking B doesn't imply fault.  Counterexample: there were cases 
where log4j had deprecated an interface for literally YEARS (I'm not 
exagerating here), and when they removed it, builds broke.

Nagging on deprecation warnings is difficult.  When the deprecation is 
initially inserted into the development stream, there has been no 
release, and projects are typically (and rightfully) reluctant to step 
up to a daily build.

> Since we know that B-yesterda built against A-yesterday, than the result 
> of the B-today against A-yesterday will tell us if it's 1) or 2)
> 
> Ok, with two projects is easy, what about three?
> 
>  C -> B -> A
> 
> worked yesterday, but today C is broken and B and A work. Who broke the 
> build?
> 
> First of all, is it safe to assume that since A is shielded by B and 
> both B and A work, A has no influence on C?

What matters is the jars that are used to build C.  If A is visible at 
all, then it it relevant.  It might not be directly involved at compile 
time, but it could be relevant at runtime.  Furthermore, compile time 
often involves things like XSLT translations, so the distinction between 
compile time and runtime is not necessary pertinent.

I remember a Xalan change that broke FOP's build for this reason.

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message