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