gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <>
Subject Re: [RT] a strategy for better gump action/reaction analysis
Date Sat, 14 Aug 2004 00:39:33 GMT
>>> 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. 
Agreed, and we just need to remove the 'blame' aspect, and consider notification, an 'FYI'
style communication.

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

Good example. Following it on, I recall Ceki didn't seem to mind knowing about the 'user'
of log4j that had problems. Sure he might berate them for not getting onboard sooner, but
he was willing to help them move. As I recall he did also revert on change, based off some
of the communications threads/analyses that followed. The 'practical/real-world interface'
(both parties & what is being used) had an event, that is what Gump is looking into. I
am starting to wonder if we can consider the usage interface (dependency, but it's implications
-- what classes/methods) as an entity w/ community ownership.

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

BTW: We have the ability to do this cross-post notification only upon the first occurence
of the event, and from then on 'nag' the breaking product ('cos it is the one that owns the
issue, IMHO).

BTW: I think Gump needs to integrate with JIRA and/or others. Allow a human to press a button
to assign an issue id to an event. Folks can register with the tracker if they care to know
about updates, etc.  Gump could attempt to emualte such tracking (and that might be wise,
or folks might need to use N differnt trackers for N different dependees) but I'd like to
consider starting with JIRA integration.

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

Plenty of A can bleed into C, especially behaviours at runtime. I think it is likely the unusual
case where there is no direct dependency.

We don't need exactly science here, we need community science...



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message