> Chuckle! You should of seen some of the hacks I had in place while
Jon was
> nudging me to publish the source. Actually, come to think of it,
I'm kinda
> glad that you didn't. ;-)
>
> Note: when I started, I knew precisely zero about XSLT.
This is understood. I am still unhappy about much of the AntGump, but
I felt I was actually holding others back because they had heard that
I was doing it, and were waiting to see what I came up with.
> > Sam, you have done some excellent work and I definetly want to
> > continue down the path while maintaining your reputation (for
> > better or worse [BIG SMILEY]).
>
> Oh, I have more than enough reputation. ;-)
And we need to keep it that way ;-)
> > Besides, I'm semi-exempt, havig not yet earned my 'Apache
> > commit karma' :-)
>
> Lets discuss this for a moment. Clearly a few people including
yourself
> have demonstrated a deep understanding of what Gump is and have good
ideas
> about what it should become.
> Let me be blunt about my concern: if I screw up, literally thousands
of
> people (perhaps even tens of thousands of people) will get an e-mail
with
> my name on it the very next morning. Perhaps dozens.
> There also are some very serious security concerns, which I do not
care to
> elaborate on at the present time.
> So what I want to discuss before opening this up a bit is how to
structure
> a "staging area" for changes. Perhaps the right thing to do is to
have a
> separate branch. Or a separate proposal directory. And it is not
that I
> don't trust people, once people are given commit authority, I will
trust
> that they only make changes into the "live"
branch/directory/whatever when
> they are fairly confident. Other changes should go into some sort
of
> staging area.
>
> Thoughts?
Barring the security concerns, which I can only aassume have to do
with the actual use of Gump within the ASF, and not the development of
Gump, I understand, agree, and really want to help.
Is Gump a tool that needs to be 'release-ready' at all times? This
may be the case. Should that hinder development, I don't think so.
On the other hand, my intention is to have a 24/7 Gump locally for
myself, but the emails would go out to management, so the same
concerns exist. I am happy to run Gump testing it semi-constantly,
doing things such as the naglist to myself, and seeing what happens.
Or perhaps we just need to release and use a particular release until
there is a better one. I am not the expert on any sort of
Baazar-style development, but continuing on the one-man path can't
last too much longer. So, I would like to help iron this out soon, as
I think Gump has a very bright future, and I want to be involved ;-)
One thing is realtively clear. Gump in CVS is two things right now,
1) a tinderbox tool, and 2) the specific implementation for the ASF.
These two things need to be separated in some fashion. I am very
happy that Sam's examples exist there now, but they probably don't
belong there, IMHO.
Short and sweet, I understand and want to help. What are your
thoughts on the further development model? I am quite happy with
branches, proposals, releases, etc. I think that we just need to do
it.
> Clearly Ant is OK. Jon and others have said that Perl is OK.
Therefore
> Python is too.
>
> My advice is to pursue your interests.
>
That is for sure ;-)
Scott Sanders
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
