gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] a strategy for better gump action/reaction analysis
Date Sat, 14 Aug 2004 00:13:59 GMT
Sam Ruby wrote:
> 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.

Artifacts reduce the build time. It's like a cache.

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

No, but my suggestion is to move away from the psychology of "fault -> 
nag" and move into the 'action -> reaction' one.

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

Right. Log4j did an action that caused a reaction. Now, this is not 
log4j's fault but a communication that needs to happen.

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

We should not indicate "who is right and who is wrong", but just 
indicate that "this action, made by this person at this particular time 
on this particular project" created a reaction on this other project 
that depends on it.

Both actor and actee (reactor?) are sent an email and you can be sure 
this will generate some communication.

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

wait, wait.

if C depends on B which, in turn, depends on A, but C and A have no 
direct dependencies and B compiles fine (which means that A compiled 
fine too), what is going to happen?


-- 
Stefano.


Mime
View raw message