gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject Re: brutus config -> lsd config
Date Thu, 01 Apr 2004 16:04:10 GMT
> >>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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message