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 goodwill. 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 ones. Basically, I think we need a way for folks to get hands on with Gump without risking nightly builds. Thoughts? regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
