Gump Sandbox

["Adam R. B. Jack" <aj...@trysybase.com>]

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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: Gump Sandbox

[Leo Simons <ls...@jicarilla.org>]

Adam R. B. Jack wrote:
> Basically, I think we need a way for folks to get hands on with Gump without
> risking nightly builds. Thoughts?

I agree. I find it a bit scary as well to make changes, especially since 
I know how limited my python skills are...I really miss the confidence a 
unit test suite gives. Need to get a little bit of my try-and-see PHP 
hacker mentality back ;)

I suggest we mark one full gump installation as UNSTABLE and one 
installation as TESTING. Every now and then (as in, whenever significant 
development bits are complete), we select a particular well-working 
UNSTABLE, tag CVS, and update the TESTING machine with that.

Failure notifications (not nags :D) are sent from the TESTING machine only.

I also think two levels of cascade is enough for now. We don't really 
need a STABLE.

Note we don't really need two machines for this (we could have two 
installs living side by sides), but since we do have two (moof and 
brutus), we might as well, since we could limit access to the TESTING 
one a little more.

-- 
cheers,

- Leo Simons

-----------------------------------------------------------------------
Weblog              -- http://leosimons.com/
IoC Component Glue  -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
  people wouldn't obey the rules."
                                                         -- Alan Bennett


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org