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.
smime.p7s
Description: S/MIME Cryptographic Signature
