gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject Re: [RT] Gump GUI development parallel to Gump Remote Agents (Sites)
Date Mon, 29 Mar 2004 18:03:24 GMT
Adam R. B. Jack wrote:

> I've not had chance to go over Leo's architecture notes in enough detail (at
> a quiet time) in order to respond to them completely. I keep wanting to find
> time. The first point that I'd like to address, when I do, is that I don't
> believe that Python Gump (I will start referring to it as Gump, implying it
> is just 2.0) reverted to a batch approach, per se.
> Maybe I am splitting hairs, but Gump can perform a 'run' of one or more
> projects, upon them alone or the dependency stack beneath them. Since Gump
> needs to behave in a certain (dependency) order when N>1, the N=1 case is a
> little bloated, but it is doable today.

Perhaps I chose the wrong words to express what I was trying to convey. 
   As usual, a picture is worth a thousand word. Take a look at the 
following urls.

At the present time, it shows a run that started just after noon on 
Sunday, and completed at 9 am the following day.  This happens to show a 
complete run.  Check back in a few hours, and depending on when you 
check, you will find partial results, either on the checkout side or on 
the build side.

I believe that this is a very valuable thing to have.

Note that when you run classic Gump from the command line, much of this 
information goes to stdout instead.  So, I say "build gump" and what I 
get is pretty much identical to what I would get if I were to type in 
"ant" from the proper subdirectory, and with all the right things in my 

This is also very valuable when inviting others into helping debug an 
integration problem.  Simply give them a login on the machine, tell them 
to make whatever changes they like (it will get wiped out next cycle 
anyway), and then type "build <project>" to see if it helps.

I was able to identify exactly where breakages was introduced on 
projects I didn't know by repeatedly issuing "cvs update -D <date>" and 
"build <project>", doing a binary search over time space until I had 
identified the exact commit that caused the problem.

Yes, we could split the gui into a client and server and solve this (or 
simply rely on XWindows), but there is value in being able to do this 
from the command line.

> The reason I care about this distinction is that I feel we don't need a
> major re-work in order to satisfy targeted runs. I think this is most
> clearly seen if we bring the GUI, that Sam/Nicola worked on, out of
> mothballs. I'd love to see that done, 'cos I think it brings good issues to
> the surface. With the GUI I think we can allow a user to pick N projects,
> and can perform an update or a run, or whatever.

A GUI is a nice thing to have, but not as a replacement for a command 
line interface.

> I also think a GUI is especially useful for resolving some of the concerns
> over documentation, and timeliness, and format. I think that a listener
> (being passed context with status) could be called whenever a project is
> built (or whatever) and could represent/display state as it proceeds.
> I've always respected the Gump GUI & liked what it brings to this mix, I've
> just never had enough cycles to maintain it as I fleshed out the more
> 'agent' way of doing things. For the GUI to really fly I believe we need
> some internals changes (separating all 'run' information into context
> objects and off the metadata model objects, so we can re-run without
> re-loading metadata) but I think this is worthwhile.
> So, my random thought is ... could we find folks to care about this use
> case, and bringing it to feature completeness as a parallel effort to the
> remote agents and their sites (via forrest or cheetah or both or ...)

While I like the GUI and can invest some cycles there, I will remain 
fundamentally a command line person for 95% of my usage.  So, my RT 
would be for us to flush out what would be required in order to 
implement a dynamic forrest approach.  Let's specify the data formats of 
what is expected to be produced by python gump.  My preference would be 
that this be semantically rich XML (i.e., lacking in presentation 
elements like spacer gifs and the like).  If this can be XHTML with CSS, 
that might be nice (with the semantic information captured in class names).

As to how we evolve from where we are to where this would take us, I 
would suggest that we simply continue to maintain in the current 
document.* classes, but start to augment the other classes to produce 
the specified data.  Once this reaches a critical mass, a dynamic 
Forrest implementation could be initiated, and only after it gets to the 
point where it is deployable would the document.* classes get deprecated.

- Sam Ruby

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

View raw message