gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [RT] Gump Architecture
Date Fri, 26 Mar 2004 11:56:54 GMT
On Thu, 25 Mar 2004, Leo Simons <> wrote:

> Traditional gump has this architecture.
> On completion, some other script files are or can be run to do some
> other things (like send out failure notifications).

which is done by a Perl script, which just adds to the tool mix of
"traditional" Gump.

> (Scripts are available to check things directly provided you have
> console access to the server, but only a handful of people
> (approximately 4 or 5 on the planet) know how to use them

But note that if you know how to use them, debugging a Gump build
becomes very effective and avoids the "wait 24 hours" part.

We really need an equivalent of this in whatever Gump ends up to be in
future iterations.  Be it easier to use scripts on a server everybody
has access to or be it via a build-on-demand webapp.

> Replace this batch concept with a command/action/event
> concept.

I think we need both.  We will always want to have some sort of
"nightly Gump build" that ensures that all projects will be updated
and built.  In the end the batch concept can be emulated by pushing
the command in via a batch job.

> - Get rid of the "giant tree transformations". It has proven to
> scale only with difficulty.

If you separate the graph building from the commands, then submitting
commands will need some help by the system.  I wouldn't want to figure
out which projects I have to build first when I say "update and build

The batch-like part I've talked about above will still need the full
graph, but I agree that the full graph doesn't need to be - and maybe
even shouldn't be - the core part of Gump.


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

View raw message