gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <>
Subject Gump Sandbox
Date Sun, 28 Mar 2004 18:20:19 GMT
I believe Gump would benefit from folks being able to tinker with it's
Python codebase, in order to get comfortable with the internals (which
always seem to act differently than visualized when run against the mungo
data set of a full workspace. ;-) and in order to attempt new approaches.

Since we now nag from Python Gump, and want to (and seem to) impact a lot of
folks/communities with those nags, we have to respect that is an
interruption. When Gump generates a false positive we are wasting community

As a Python newbee (especially one without local resource to do full runs
prior to checkin) I found it daunting that each night the latest/greatest
Gump code gets checked out & run. I try to do incremental changes, I try to
write unit tests, but I feel awful if a build fails because of something I
was experimenting with. I think this is a barrier to
creativity/extension/experimentation, and is slowing Gump progress.

I like that we 'eat our own dogfood' and run the latest from CVS HEAD, but I
also worry we aren't following the tried and tested DEV/TEST/PRODUCTION
methodology. Perhaps we could separate descriptor CVS from code CVS (SVN),
and us only update the descriptors each night. Maybe the nag workspace is
separated from test workspaces, and/or we specifically install some test

Basically, I think we need a way for folks to get hands on with Gump without
risking nightly builds. Thoughts?


Experience the Unwired Enterprise:
Try Sybase:

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

View raw message