> >>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?
Brutus is a good master to clone, unless tomcat/forrest add more dependencies, that was all. We just haven't tried it yet, and I was just trying to be exact. > 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? So forrest bundles tomcat or similar? Huh. I guess I did see that with the 'forrest run' command, I just filtered it out, thinking we'd not want users (like gump) doing such stuff in a multi-user environment. Translation -- I was waiting for 'admin' to install something. :-) > > 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. Yup, I saw. I'm not stuck on these, I am just trying to raise the awareness that this was more an OSX decision, not a Gump community one. Packages in /opt seem good 'cos they are static. Workspaces in /var seem good, etc. I really don't know if there are standards or conventions on the various flavours and OSs, but if there are, I'd like to follow them. > > 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 > > ? Err, good question. ;-) History? I wrote gump.sh (for traditional), then gumpy.sh, then (sometimes I'm slow to see things) it dawned on me a gumpy.py would be a nice idea (to avoid the need for .bat, and more folks were testing on M$). I started work on gumpy.py being careful not to use gump.* packages so we could wipe *.pyc [not done in gumpy.py yet, see archives for TODOs] and also CVS update Gump. I added some nice features, like reading the workspace file (using minidom) to extract certain variables -- even mailing failures. I made great progress, and it sorta works, I just never cracked the environment issues (and hup also caused me some grief). Daft, but I got 'stuck' on thinking that if I were shooting for a *.py I ought not have a *.sh. > For that matter, the cron command can look something like this (omitting > paths): > > bash -c "(. local-env-py.sh; python gump.py)" Don't ya love how one persons block is another persons simplicity? Sure, when not. Better a one liner *.sh using gumpy.py than not using gumpy.py... Let me take one last look into gumpy.sh and gumpy.py and we do exactly what you just said. > > 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. I've tinkered with this on and off, but not had a separate flag for 'official'. I think it needs to be introduced. (There are mutiple places where we check isFull() [i.e. 'all' projects not some] -- and we have the integrate script different (in what it does) than build or update or debug. There are even comments in the code about 'if official then nag and/or do rss/atom', but much has been removed since I like to test the whole path (quickly) on subsets of a profile.) This brings me onto configuration, see next... regards Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
