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.
http://gump.covalent.net/log/cvs_index.html http://gump.covalent.net/log/index.html
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 CLASSPATH.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
