[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gump
Subject:    Re: first impressions on gumpy
From:       "Adam R. B. Jack" <ajack () trysybase ! com>
Date:       2004-07-27 19:00:42
Message-ID: 0bc001c4740c$5ef54b60$13b5ea43 () sybase ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]