gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [RT] Improving on gump
Date Wed, 21 Apr 2004 10:59:30 GMT
Adam R. B. Jack wrote:

>>+Currently our [http://lsd.student.utwente.nl/gump/#Project+Summary
> 
> success rate]
> 
>>+is 75.34% with 592 projects.
> 
> 
> It got into the 80s until one sole unit test in one project brought a bunch
> of stuff tumbling down, and it hasn't been fixed. :(
> 
> Personally, I'm starting to but that we ought to gump on latest gump
> produced jars (so deeper project get a shot at (at least) finding their own
> mistakes, or ones they cause others). Other than technically (how to do
> this, or that this is imperfect) did any serious opposition occur to this
> idea? Pointer to a thread would be welcomed, as would a 'design decision'
> entry in the wiki...

I'm in a ISO meeting so I don't have much time, but I so much would like 
us to start using gump in two ways:

  1) as continuous integrator
  2) as nighly build tool

the difference is that when Project A depends on Project B, the 
continuous integration mode does

  get latest B
  build it
  if successful {
    get latest A
    build it
    if successful {
       // do nothing since everything is cool
    } else {
       send email to A
    }
  } else {
    send email to B
  }

Now, the problem with this approach is that if B is broken, we have no 
way to help A until all the dependencies have been fixed. While the 
principle of continuous integration is *outstanding* and probably the 
biggest improvement in software development in a decade, I think that 
should not preclude other uses of the software.

So, my proposal is to use Gump like this:

  get latest B
  build it
  if successful {
    get latest A
    build it against latest B
    if successful {
       // do nothing since everything is cool
    } else {
       send email to A (
         with results from A build
       )
    }
  } else {
    get B that A says it depends on (out of timestamp)
    build it
    if successful {
       get latest A
       build it against dependent B
       if successful {
          send email to B (
            with the results from latest B built
          )
       } else {
          send email to A (
             with results from A built
             with list of broken dependencies
          )
    } else {
       send email to A copying B (
          with results to targetted build
       )
    }
  }

This can be done with computational feasibility because it downgrades 
only when necessary (and shouldn't be much at regime) and the advantage is:

  1) more precise nagging (we can now understand who broke what, just 
can't estimate when (yet!))
  2) projects that are disconnected by a breakage can still receive 
feedback on what they are doing (critical for complex projects like cocoon!)

the only thing missing is that our current project metadata doesn't 
contain information on what tag/timestamp the project is dependent on, 
but we can start adding that information incrementally, or let projects 
know that this ability is available and they will fly to update their 
descriptor files!

Comments?

-- 
Stefano.


Mime
View raw message