> > Note: I think I need folks to recognize that gumpy.sh is NOT the main point > > of contact for Gump (yet I keep finding folks starting there). Are these > > script so invisible/unapproachable? > > assuming that geeks will read docs is wishful thinking. > > I had to run "gumpy", I saw a script called "gumpy.py" and I run that > and it worked somewhat. There was no need to look around for other things.
Yup, I hear that. When we do the re-organization I think we ought move certain things into a bin directory (a place where folks start looking) and move the cron stuff into cron (or something). Definately come at this from a new user perspective. For example, the command line gump tools, since they are entry points -- they do not need to be in a gump package. Yup, this is good food for thought. > > > http://wiki.apache.org/gump/GumpScripts > > http://wiki.apache.org/gump/GumpCommandLineOptions > > > > Nicola started a 'gmp' wrapper to try to put a single point of human contact > > onto these things, and it works, but maybe needs some polish also. > > may I suggest to call that unification wrapper "gumpy" and have a > "--cron" option or something that makes it work like a cron job? Reading down, just got here ... but yes (see above) I now get that. > > Hmm --- as soon as we migrate to SVN and deprecate traditional I'll work to > > re-do the site and mention some of this information. > > I'm at OSCON, I'll force the infra@ guys to do it ;-) ;) > >>- why provide and workspace are in different files? > > > > The profile contains the list of modules/projects. The workspace is one's > > local configuration (locations on disk, etc.) One can share/re-use a profile > > (e.g. profile/gump.xml), one typically does not share a workspace. > > gotcha (might be nice to have this information *inside* the documents as > comments. again, people interested in gump are not the people that will > read docs ;-) True, good feedback. > >>- workspace "email|maillist" should be "to|from" since you might not > >>want to send it to mail list but to yourself > > > > Yup, agreed 100%. Since we started having a few remote Gumps, and since we > > don't have releases (every commit get's run) I was worried about > > element/attribute name changes. I once started a mail on metadata > > deprecation/migration (and how we do it in Gump) and this is what we need > > here. I'll try to get to that. > > Gump is not a released official product and we have no > back-compatibility plan for now (and there are not so many installations > around). I think it's a better to cleanup things now than later. > Yeah, that is probably true. > >>Overall experience: not so bad, but it *definately* needs polishing... > >>it totally feels like a system that only one guy uses :-/ we'd better > >>fix that. > > > > > > Please. :) > > I have thought about it *very* seriously and I will stick to Gumpy > instead of rewriting my own version in Java. Awesome, glad to hear that. Yes, there is a lot of 'grunt work' to be done that is pretty much the same in any language, I'd rather not see that re-written. I do think there is 'hope' for this codebase. > but we need to cleanup the repository very fast because it's too messy. > > I'll bug the infra@ people > Thank you, 'cos I'm itching to do a bold clean-up. regards, Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]