The Python version is an experiment. The primary purpose of the
experiment was to test assertions that a codebase which was based on a
real scripting language and without a dependency on XSLT would attract a
greater community. So far, it hasn't demonstrated that assertion.
Thank you for this answer, it is information I can work with. I admire your
ability to keep objective as to the status of things.
As for community attraction, does that attest to the choice of language or
to the type of product Gump is? Everybody wants distributed/cross-project
builds to work well, but I suspect few are so inclined that they'll
contribute time to assist it. Do you really believe that Python Gump has
less community interest than Java/XSLT/Bat/Shell/Perl Gump, or is it that a
working Gump exists, so why change it?
I know this has been a lot of work on you/Nicola, but I believe (from my
observations) that a consistent Python solution has far greater community
appeal than the hodge podge. I think it might just take more seed work to
get it ready, get it out there, spread the word that it is changing &
wanting more users, and see it used.
My focus to date with this code base has been to explore things that
would have been difficult if not impossible with the current
Java/XSLT/bat/sh approach. The parts I have not focused on were the
ones that I knew were doable.
Understandable (I'd just not spotted that). Reading between the lines, I
assume that if Python Gump continues it'll support the command
line/automated/remote use case. If it does, I'll happily assist w/
testing/feedback & however else I can.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
