gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Nagging the cause vs. Nagging the effect
Date Thu, 05 Feb 2004 14:22:08 GMT
On Thu, 5 Feb 2004, Stefano Mazzocchi <> wrote:
> On 5 Feb 2004, at 02:17, Adam Jack wrote:
>> I've long wished that Gump could nag the 'cause' of a problem, not
>> the 'effect', but it is (AFAICT) pretty much impossible to guess
>> who is cause from a compile failure.
> Tell you what: there have been looooong discussing about this and
> endless hours that I spent on the whiteboard trying to figure out
> *where* that data can emerge out of the entire mass of data that
> gump is either collecting or generating.
> I was still not able to find it, still not able to come up with a
> general algorithm that would, at least, if not identify the cause,
> at least discriminate between "causing trends" and "effected
> trends".

The way you'd do it manually is about as follows, I believe:

* start with the last good build

* replace one of the dependencies with its latest version at a time
  and rebuild - reiterate until the build fails.

Gumpy should have enough data to do that, but the whole thing breaks
down when Gump has been unable to build a project for weeks or even
months as the number of changes becomes too big.

> I think the key is that the gump runs as for Gump or Gumpy do *not*
> contain enough information. But if we had both:
>   1) the latest dependency run
>   2) the stable dependency run
> and we had enough history of these (say a few months), I'm pretty
> sure the data *IS* there.

I think Gumpy already collects, or at least could collect, historical
data for all dependency runs.  If the dependency run has been
successful at least once, the data is supposed to be there.

I realize that this is naive. 8-)


View raw message