Adam R. B. Jack wrote:

Are we happy with the gump config on brutus? Is that setup reasonably
stable?

Unless we decide to move to tomcat/forrest, I'd say so.

How should that change things? What's the next step?


Apparently running a forrest server on a different port is as easy as a executing a command. So I would think that the next step would be to get gump to produce xdocs during the run in addition to the static documents at the end of the run. Once this was done, forrest can be used to dynamically produce content from these xdocs. Does this sound about right?

If there is anything I am not sure I like about the set-up is that we
mirrored the /usr/local/gump from Moof, and I'm not sure if that directory
is the best root one on all. I like things like /var/gump and
/opt/gump/packages and things like that, and (maybe) /home/gump. But, so
long as we can find choices (or a choice) that suits norms on these
platforms, I don't really care.

I already did a few symbolic links from /home/gump to strategic points in /usr/local/gump; we certainly can do a few more from /var and /opt.


Oh yes, and I'm still not sure about .bash_profile including one flavours'
local-env-py.sh. I didn't take Sam up on his posting (I forget when/werre)
that said, don't expect these settings in cronjob. As such, we are still
using gumpy (that works, but is ugly since it needs three more env variables
& doesn't read the workspace to get the values) not gumpy.py.

Why isn't gumpy simply:


  . local-env-py.sh
  python gump.py

?

For that matter, the cron command can look something like this (omitting paths):

bash -c "(. local-env-py.sh; python gump.py)"

I think we need to ensure we have a 'test' flavour [or test workspace
perhaps] on every box, one that we expect folks to tinker with (when the
main build isn't running). A test workspace would work [other than the fact
it could mask 'updated'] because we'd only run it at odd times, and we'd not
crap on the same output tree (like I often do testing.)

Can I suggest a different approach? What I used to do with classic gump was to capture and datestamp the outputs of the "official" runs, keeping a fixed number live. This is a simple matter of copying a few directories at the end of the run.


- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to