gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <>
Subject Re: [RT] Moving gump forward
Date Mon, 08 Mar 2004 08:26:59 GMT

In message <>, Stefano Mazzocchi writes:
>Now, I think it's possible (even if computationally expensive) to 
>understand exactly what commit broke the build and to nag the exact 
>person and the community and copy all the offended people.
>for those not familiar with exponential growth, it's enough to say that 
>if the build took a minute it would take gump 2,5 billion years to find 
>out what broke the build.

Why don't you start with the easy stuff.  If a build of project A
fails, we know all builds depending on project A will fail.  But
if project A is dependent on project B, and project B failed, then
we keep on walking up the tree to find the first build that failed.
Okay, so now that leaves the issue of a build failing because of
an API or some other change in a dependent project that built
successfully.  For projects with a small number of dependencies,
use the brute force approach you described.  For projects with a
large number dependencies, develop some heuristics.  You can
reason that if project B makes a change that breaks project A and
if C also depends on project B, then there's a chance project C
might also have broken.  Since Gump builds a ton of code bases,
a decent number of culprits (i.e., project B) could be identified
by analyzing the dependencies shared by projects that failed to
build.  You can then apply the brute force approach to only those
shared dependencies if they number below some manageable figure.
Another heuristic approach that would work for Java projects at
least, would be to analyze the build failure messages.  Usually
they'll reference a class or class member/method that is in
a dependent code base.  Develop an evolving library of patterns
to extract the offending methods/classes/etc. and then discover
what jar they came from.

Anyway, those are some inelegant, inxact, and simplistic--but perhaps
useful in some instances--suggestions about how to start adding the
functionality you describe that would buy time to figure out how to do
it right.  That is, assuming it's a hard problem that requires a good
while to figure out.  My reasoning is that it's okay to nag the
wrong projects every once in a while as long as you nag the right projects
most of the time.  And on first glance, based on your comments, it seems
easier to implement that than to figure out the right project to nag all
the time.


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

View raw message