You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by "Adam R. B. Jack" <aj...@trysybase.com> on 2003/09/25 22:19:32 UTC
Sanity Check & Gump Community [please read/respond]
I'd *really* appreciate feedback on these thoughts. If you only answer one
mail from me, please make it this one. The topics are:
1) Sanity check on what I'm doing w/ Gump (or hoping to)
2) Internal Community
3) External community
First, I'd like to solicit some constructive feedback (and I'm not the type
that looks for/wants pats on the back, I mean constructive). Also, I'd like
to hear if you -1/-0/0/+0/+1 where I am trying to take Python Gump, and if
(some time in the future) you could support Traditional Gump being replaced
by it. (Don't forget, I am new to Jakarta, so I don't know if there is a
process for what I am asking here. If anybody would like to tweak what I'm
asking, please do.) Along these lines, could I get vote-style feedback on:
*Python Gump (as a future replacement for traditional Gump)
*Python Gump using Forrest
*Gump Statistics (as a tool for automatically communicating
reuse/reliability/robustness, etc.)
*Gump and Ruper (using Ruper to download packages)
*Distributed Gump Trees (also using Ruper to download upstream Gump outputs)
*Gump Documenter (as a tool for communicating the OSS map, and promoting)
*Promoting more gump projects in public Gump (do resources exist, will the
7+++ hours grate on Stefan?)
*Promoting more public/private/personal Gumps.
*Promoting more OSS Gumps (e.g. on SF.net. on Java.net, etc.)
Questions: Anybody got any other itches they'd like to see scratched by
Gump? I'm not volunteering, per se, just curious.
Second, internal community:
I've asked for help on forrest, and on CVS, and on a number, and folks
haven't had time to help me. That is ok, that happens. Also, I fear I
contribute to it, by having enough time (right now) to dig in incessantly. I
don't want to discourage community, I welcome/want that, and I don't know if
I am helping it, or not. That all said, I need to make value judgements. The
stats from the votes above will tell me a lot, but I need to figure out a
what point I've contributed to Python Gump's momentum, and if it has
critical mass. I am game for the long haul (family/life/work willing) but
[like Sam] I don't want to take the Gumpy journey alone. Further, I don't
want to do what nobody else wants, nor will use.
Gump is incredibly valuable, I have no doubts about that, but it mustn't
stagnate w/o reaching it's potential. I see folks commit time to configure
projects, I see folks benefit from the outputs. That said, how do we promote
a community of folks who care enough to maintain the service? I think too
many people don't know Gump, nor it's potential, they just expect the
service (like they do CVS). Is there a way we can make a concerted effort to
promote Gump, and request developers? Thoughts?
Third, external community:
External community is key, and I see Gump as closed to those 300 or so
modules it supports. Ought we propose a Gump on SF.net, or on java.net, or
wherever? I think Gump's strengths are best felt with a large profile, so
much as the GUI Gump is cool, I think big public Gumps are invaluable. Has
anybody suggested a Gump on SF.net to SF.net, to others? Now that Gump is
far easier to install (than when Andy Oliver tried) it really ought be
possible for folks to have their own. Is this a good thing for future Gump?
What do folks think about Gump's future, about what it ought be trying to
be, about who it ought be targeted at?
Thanks in advance for all responses.
regards
Adam
--
Experience Sybase Technology...
http://www.try.sybase.com
Re: Sanity Check & Gump Community [please read/respond]
Posted by Leo Simons <le...@apache.org>.
Adam R. B. Jack wrote:
> [please vote:]
> *Python Gump [as replacement]
+.5. +.5 means that I think its a good idea, would like to contribute,
but have no time to do so.
> *Python Gump using Forrest
0. (though we shouldn't loose the immensely useful one-glance
red/yellow/white coloring)
> *Gump Statistics
-.5. Could be okay if 'done right'. Statistics always get abused all
over the place.
> *Gump and Ruper
+.5
> *Distributed Gump Trees
+.5
> *Gump Documenter
?
> *Promoting more gump projects in public Gump
+0. Key point here is that what we cannot have is more projects being
added but not more admins coming in to help. As it stands now, a handful
of people maintains a s**tload of descriptors. That does not scale.
> *Promoting more public/private/personal Gumps.
+0. First step is making it easy. After that, darwinism should help :D
> *Promoting more OSS Gumps (e.g. on SF.net. on Java.net, etc.)
+0. promotion of continuous integration in general is a good idea. IMHO
it would not be bad to have some "marketing" applied to gump (or a
number of ASF projects). But I'm not about marketing, I'm a programmer :D
---
> Anybody got any other itches they'd like to see scratched by
> Gump?
Just like people should run unit tests when they rework code, they
should run a continuous integration tool. We need a way to make that
happen. Gump could be part of that. I have a hunch that maven is, too.
> I don't know if I am helping [community growth], or not.
me neither. Community engineering is a difficult science :D
> I [need to know when gumpy reaches critical mass]
I think: not yet. Critical will be when it can and will replace the
other gump. In the long haul, we don't have resources to support both.
> I am game [but] I don't want to take the Gumpy journey alone.
building an OSS project community is hard. Especially when a lot of the
job is "unsexy". Gump is not sexy. It will remain difficult to get
people to work on it.
> Gump is incredibly valuable, I have no doubts about that, but it mustn't
> stagnate w/o reaching it's potential. I see folks commit time to configure
> projects, I see folks benefit from the outputs. That said, how do we promote
> a community of folks who care enough to maintain the service? I think too
> many people don't know Gump, nor it's potential, they just expect the
> service (like they do CVS). Is there a way we can make a concerted effort to
> promote Gump, and request developers? Thoughts?
Again: community engineering is a difficult science :D
Maybe we should actually stop thinking of gump as a software project
and/or tool and more as an infrastructure service. Maybe we should
reverse that, and force the users of gump to use it actively in some way.
Maybe someone should take time to put gump on the jakarta/asf agenda by
raising all these questions on community@apache, general@jakarta,
general@xml, etc.
Maybe we should just keep making it easier to the point where you just
add <gump/> to your ant buildfile or type 'maven integrate'.
> External community is key, and I see Gump as closed to those 300 or so
> modules it supports. Ought we propose a Gump on SF.net, or on java.net, or
> wherever?
work, work, work :D Yes, but we really do need volunteers to maintain
them. Can't do that ourselves. I'm sure you could get someone or
something to donate (tech) resources, but what we need is people...
> I think Gump's strengths are best felt with a large profile, so
> much as the GUI Gump is cool, I think big public Gumps are invaluable. Has
> anybody suggested a Gump on SF.net to SF.net, to others? Now that Gump is
> far easier to install (than when Andy Oliver tried) it really ought be
> possible for folks to have their own. Is this a good thing for future Gump?
not sure.
---
hope this helps you make up your mind :D
cheers!
- Leo
Re: re Friend of gump was Re: Stefan's comments on Gumpy
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 26 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:
> Basically, I feel it'd be nice to be able to judge based upon simple
> facts, and if krysalis-* set needed to be nice friends of gump (and
> their dependees) then it ought be apparent.
See <http://cvs.apache.org/~bodewig/gump/> from my last nightly build.
I've only uploaded the logs fot the krysalis builds, not all logs so
most links are probably dead.
The builds I've been talking about are krysalis-antlibs-all,
krysalis-ruper, krysalis-centipede-site and krysalis-version-antlib.
Some others are failing as well.
Stefan
Re: re Friend of gump was Re: Stefan's comments on Gumpy
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> > I would say centipede is not very gump freindly right now. And people
> > should be aware about that. More importantly krysalis needs to fix it.
>
> Now my personal gump does work most nights.
> But we did have a long period of no success.
This is where statistics (and the module based, not project based, view in
Gumpy) would help. :-) I think there are far more krysalis-* projects
succeeding, than failing, but the current interface doesn't make that clear.
Basically, I feel it'd be nice to be able to judge based upon simple facts,
and if krysalis-* set needed to be nice friends of gump (and their
dependees) then it ought be apparent.
Just my tuppence.
regards
Adam
Re: re Friend of gump was Re: Stefan's comments on Gumpy
Posted by Nick Chalko <ni...@chalko.com>.
Nick Chalko wrote:
>>
> Yes we know krysalis are failing consitently. (I guesss I am
> allowing myself to be asleep at the wheel).
> The continued gump failures are one of the reasons POI stoped using
> centipede.
>
> I would say centipede is not very gump freindly right now. And people
> should be aware about that. More importantly krysalis needs to fix it.
Now my personal gump does work most nights.
But we did have a long period of no success.
>
> R,
> Nick
>
>
re Friend of gump was Re: Stefan's comments on Gumpy
Posted by Nick Chalko <ni...@chalko.com>.
Stefan Bodewig wrote:
>>BTW: What bugs me is if product X changes it's API (or fails to run
>>unit tests) and hence breaks innocent product Y, then Y gets the bad
>>mark. If X is then stagnant/unresponsive, Y gets slammed. I don't
>>see a way that Gump can detect it was X that broke Y, and not Z. Now
>>I realize that Y will eventually move off X,
>>
>>
>
>Very unlikely, even for projects that consider themselves "friends of
>Gump". When has Gump tried to build Cocoon or Forrest the last time?
>Are you aware that almost all krysalis-* projects fail every night
>"because Centipede has not been not initialized"? 8-)
>
>
Yes we know krysalis are failing consitently. (I guesss I am allowing
myself to be asleep at the wheel).
The continued gump failures are one of the reasons POI stoped using
centipede.
I would say centipede is not very gump freindly right now. And people
should be aware about that. More importantly krysalis needs to fix it.
R,
Nick
Re: /k-* (was Stefan's comments)
Posted by Nick Chalko <ni...@chalko.com>.
Stefan Bodewig wrote:
>On Tue, 30 Sep 2003, Nick Chalko <ni...@chalko.com> wrote:
>
>
>
>>krysalis-template-smoketest.
>>
>>
>
>After adding ant.home to the descriptor: <http://cvs.apache.org/~bodewig/gump/>
>
>
>
Strange that is not what I got from the command line
I will keep looking
Re: /k-* (was Stefan's comments)
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 30 Sep 2003, Nick Chalko <ni...@chalko.com> wrote:
> krysalis-template-smoketest.
After adding ant.home to the descriptor: <http://cvs.apache.org/~bodewig/gump/>
Stefan
Re: /k-* (was Stefan's comments)
Posted by Nick Chalko <ni...@chalko.com>.
Stefan Bodewig wrote:
>I'll try to find some time and run a -debug build of one of the
>failing krysalis projects. Any suggestion which one I should try
>(they basically look like the same failure to me).
>
>
>
krysalis-template-smoketest.
But it seems to be turned off.
I will turn it back on.
>Stefan
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>
>
Re: Gumping centipede
Posted by Nick Chalko <ni...@chalko.com>.
Nicola Ken Barozzi wrote:
> Nick Chalko wrote:
>
> ...
>
>> BUILD FAILED
>> C:\krysalis\krysalis-template\smoketest\build.xml:9: import requires
>> support in ProjectHelper
>
>
> Seems like Eclipse is using it's own Ant. 1.5.4 doesn't indeed have
> support for import in ProjectHelper.
>
Perhaps.
I did some funky stuff and forced the imported file onto the importstack
and I got further but then had other problems.
I am still playing.
Re: Gumping centipede
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nick Chalko wrote:
...
> BUILD FAILED
> C:\krysalis\krysalis-template\smoketest\build.xml:9: import requires
> support in ProjectHelper
Seems like Eclipse is using it's own Ant. 1.5.4 doesn't indeed have
support for import in ProjectHelper.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Gumping centipede
Posted by Nick Chalko <ni...@chalko.com>.
Stefan Bodewig wrote:
>I've updated the logs with last night's build (ant-contrib-tests has
>been hanging and I had to terminate it manually in case you're curious
>about the build times).
>
>See also <http://cvs.apache.org/~bodewig/gump/krysalis-version-debug.log>
>for a manual invocation with
>
>./build.sh krysalis-version dist-gump -debug -logfile /tmp/krysalis-version-debug.log
>
>
I am trying to replicate the problem in eclise (so I can step through
the code) but I get this
[centipede] set 'core.antlib.dir' to
'c:/tools/ant/tools/antlibs/core-0.0.1-dev.antlib'
[centipede] import file :
//c:/tools/ant/tools/antlibs/core-0.0.1-dev.antlib/xbuild.xml
BUILD FAILED
C:\krysalis\krysalis-template\smoketest\build.xml:9: import requires
support in ProjectHelper
at org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:131)
at
org.krysalis.centipede.ant.ImportAntLibTask.execute(ImportAntLibTask.java:219)
at
org.krysalis.centipede.ant.CentipedeTask.importCoreXbuild(CentipedeTask.java:84)
at
org.krysalis.centipede.ant.CentipedeTask.execute(CentipedeTask.java:63)
at
org.apache.tools.ant.UnknownElement2.execute(UnknownElement2.java:205)
at org.apache.tools.ant.Task.perform(Task.java:401)
at org.apache.tools.ant.Target.execute(Target.java:338)
at
org.apache.tools.ant.helper.ProjectHelperImpl2.parse(ProjectHelperImpl2.java:148)
at
org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:126)
at org.apache.tools.ant.Main.runBuild(Main.java:653)
at org.apache.tools.ant.Main.startAnt(Main.java:220)
at org.apache.tools.ant.Main.start(Main.java:184)
at org.apache.tools.ant.Main.main(Main.java:267)
Total time: 1 minute 52 seconds
Still looking
Re: Gumping centipede
Posted by Nick Chalko <ni...@chalko.com>.
I confirmed this on my laptop at home last night using 9/28 CVS of ant
from the command line (not gump)
I will start debugging it tonihgt.
Stefan Bodewig wrote:
>I've updated the logs with last night's build (ant-contrib-tests has
>been hanging and I had to terminate it manually in case you're curious
>about the build times).
>
>See also <http://cvs.apache.org/~bodewig/gump/krysalis-version-debug.log>
>for a manual invocation with
>
>./build.sh krysalis-version dist-gump -debug -logfile /tmp/krysalis-version-debug.log
>
>and an empty CLASSPATH (using JDK 1.4.2).
>
>When you try to parse this, you should know that
>/home/bodewig/dev/gump is a symlink to /javastuff/gump.
>
>On Mon, 29 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:
>
>
>
>>It isn't a property but a static variable we test (I forget why we
>>stopped using a property).
>>
>>
>
>Sounds like a potential classloader problem then. If centipede's
>classes get loaded twice via different class loaders, you'll get two
>instances of the same class that don't share the same static
>variables.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: gump-help@jakarta.apache.org
>
>
Re: Gumping centipede
Posted by Stefan Bodewig <bo...@apache.org>.
I've updated the logs with last night's build (ant-contrib-tests has
been hanging and I had to terminate it manually in case you're curious
about the build times).
See also <http://cvs.apache.org/~bodewig/gump/krysalis-version-debug.log>
for a manual invocation with
./build.sh krysalis-version dist-gump -debug -logfile /tmp/krysalis-version-debug.log
and an empty CLASSPATH (using JDK 1.4.2).
When you try to parse this, you should know that
/home/bodewig/dev/gump is a symlink to /javastuff/gump.
On Mon, 29 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:
> It isn't a property but a static variable we test (I forget why we
> stopped using a property).
Sounds like a potential classloader problem then. If centipede's
classes get loaded twice via different class loaders, you'll get two
instances of the same class that don't share the same static
variables.
> This time it is me that does not follow, 'cos (1) POI is nothing to
> do with me (2) POI gave up on centipede long ago, and uses plain
> ant.
My only exposure to a build using centipede has been when I tried to
debug a problem with POI's builds in Gump some months ago when they
still used centipede. And at that time I found the nested <ant>
invocations incredibly difficult to follow, in particular since a
bunch of <antcall>s could have been depends attributes on targets as
well. Things may have changed since then.
Stefan
Gumping centipede
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> Which variable in which log?
Looking at this:
http://cvs.apache.org/~bodewig/gump/krysalis-version.html
(Which incidently works on Chalko.com w/ a canned Ant from a few weeks ago)
http://gump.chalko.com/krysalis-version.html
I see:
Buildfile: centibuild.xml
[centipede] Initializing Centipede [org.krysalis.centipede version
1.0.0-beta6-10001]...
which shows centipede is included/run.
It isn't a property but a static variable we test (I forget why we stopped
using a property).
Anyway, some sort of exception must be occuring and not logged (or
something) for that variable not to run.
This is *IMNSHO* quite possible 'cos between that log line and setting the
variable is some reasonably significant stuff, including files, registers
ant property handlers, etc. I'm not sure why an exception is not logged
though.
> If you can tell me what property you expect to get where, I may have a
> chance. I haven't looked at the krysalis builds yet, but when I tried
> to debug a POI problem several weeks ago you simply lost me with your
> multiple nested levels of <ant> and <antcall>.
This time it is me that does not follow, 'cos (1) POI is nothing to do with
me (2) POI gave up on centipede long ago, and uses plain ant.
> I'll try to find some time and run a -debug build of one of the
> failing krysalis projects. Any suggestion which one I should try
> (they basically look like the same failure to me).
Yes please. Krysalis-version please, 'cos we see that runs on chalko.com w/
older ant.
regards,
Adam
Re: /k-* (was Stefan's comments)
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 29 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:
> Annoying that this must've started happening about when nags
> stopped,
I'm not sure, but I think I've even seen them before that.
> What is so interesting is that it is complaining about a static
> variable that one ant task sets (and I see it called in the logs)
> that another tests.
Which variable in which log?
> Any chance you could think of anything that has changed within Ant,
a lot, sorry. We've been rather busy as we want to release 1.6beta
soon (errm, tomorrow IIRC).
> to do with including ant taks
including in what way?
> and such, that might (possible) give us a starting point?
If you can tell me what property you expect to get where, I may have a
chance. I haven't looked at the krysalis builds yet, but when I tried
to debug a POI problem several weeks ago you simply lost me with your
multiple nested levels of <ant> and <antcall>.
I'll try to find some time and run a -debug build of one of the
failing krysalis projects. Any suggestion which one I should try
(they basically look like the same failure to me).
Stefan
Re: /k-* (was Stefan's comments)
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> As long as you don't believe you could solve the social problem of
> "don't like to rely on others" via a technical solution ...
No. As I said, I'd just like to try to swing the balance a bit closer to
re-use through good clean communications (including statistics).
Maybe I am more trying to help folk prior ro making the build/borrow
decision. If a team is trying to make a decision to use (say) some XML bean
thingie, and some members of the team argue aginst re-use 'cos XYZ isn't
blah, it'd be nice to have some facts to make a proper decision upon. For
example -- N folks are already using it, it has M stability/maturity, etc.
Getting developers to use one's toothbrush will still be easier than getting
them to use one's software, but perhaps we can get it to rank above
flossing. ;-)
> You said that projects could switch components they rely upon if those
> components would consistently fail to build with Gump and I said that
> would be unlikely.
Maybe, at the level of the examples you've given.
I'm working with others to re-write Ruper making commons VFS (cool, but
perhaps overkill) an optional component. The final straw was an ongoing gump
issue [making all ruper dependees crash horribly] that saw no action for way
too long. I'm not saying it is easy, but it is an option and some times it
is mandatory.
Gump helps demonstrate divergences, and having statistics/communications
that clearly document 'recent history' (saving humans from using gut
feelings alone) have potential to be a good thing (IMHO).
> >> Are you aware that almost all krysalis-* projects fail every night
> >> "because Centipede has not been not initialized"? 8-)
> Every night. You don't see them as nagging doesn't work at all (the
> one from Sam's machine) as nightly Gumps are broken, currently. Maybe
> I should publish my nightly results until Sam's builds are up again.
>
> But then again, you should be able to see the failures un
> gump.covalent.net as well.
I looked into to the problem (thanks for the posting it). Annoying that this
must've started happening about when nags stopped, and that Nick's gump (he
didn't have resources to build the ant stack) -- or perhaps when Ruper and
above was a mess due to VFS/HttpClient. I was thinking it was environmental
on your machine, but no, it is (as you say) on Covalent also.
What is so interesting is that it is complaining about a static variable
that one ant task sets (and I see it called in the logs) that another tests.
For that variable not to be set, an exception would have to occur (at best)
but I see nothing from ant on that, so maybe there is something deeper. Any
chance you could think of anything that has changed within Ant, to do with
including ant taks and such, that might (possible) give us a starting point?
> > If you are running latest Ant,
>
> You are joking, right? ;-)
> Sometimes it is more recent than CVS HEAD.
No, just demonstrating that the contents of my e-mails are sometimes more
recent than the contents in my HEAD. ;-)
regards
Adam
Re: GUI/Stats/Gumping stuff (was Stefan's comments)
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 26 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:
>> The single most important feature for me is that it can run at
>> night from cron with nobody around
>
> I have the same use case, and I thought I wouldn't like the
> GUI.
"wouldn't like" is not exactly true. It's a nice to have, but not
important to me. Being able to run stuff without the GUI is
important.
> Ok, where on earth is this timeout feature?
Sam posted a Linux executable named timeout here, I'm not sure where
he found it. Running strings on it didn't reveal anything useful,
sorry.
My cron job does
bash gen.sh -cp "/usr/local/bin/timeout 1200"
which prefixes all executions in update.sh and build.sh with the
timeout invocation. It is supposed to kill any process that runs
longer than 20 minutes and works quite well in most cases - but
sometimes fails if the java process forks a new VM like during Cactus
builds.
> I beleive that many developers don't like to rely upon others, so
> don't re-use if they can avoid it, I've seen it even on
> Jakarta. With commons/sandbox and even incubator I feel there is the
> chance for lots of non-cooperating projects, and I don't like
> that. I am not naive enough to think that all software can/ought
> work together, but I'd like to see Gump help shift the
> balance.
As long as you don't believe you could solve the social problem of
"don't like to rely on others" via a technical solution ...
>> Very unlikely, even for projects that consider themselves "friends
>> of Gump". When has Gump tried to build Cocoon or Forrest the last
>> time?
>
> But shouldn't it? Couldn't it? Why not - resources? complexity?
We could go by them case by case, but I don't think thta is necessary.
You said that projects could switch components they rely upon if those
components would consistently fail to build with Gump and I said that
would be unlikely.
Cocoon doesn't get built because of missing pre-reqs coming from
Avalon, mostly. Last night it has been xmlutil and store.
If you follow the dependency chain, you'll see that the reason that
excalibur-store doesn't build is that it relies on the qdox definition
inside of cocoon's own descriptor which is broken.(it should be
qdox-1.2.jar istead of 1.1).
This means Cocoon doesn't build since many weeks, partly because its
descriptor is broken and nobody cared enough to fix it. Unfortunately
I can't fix it since I don't have commit access to the descriptor
itself. I didn't investigate why Cocoon's build was broken until just
now, that's why I haven't send a patch, yet.
Forrest obviously can't drop its Coccon dependency easily, that's the
original point I was trying to make.
>> Are you aware that almost all krysalis-* projects fail every night
>> "because Centipede has not been not initialized"? 8-)
>
> No, not at all. I monitor them, as do others, and they work. I've
> not seen nags to this effect, have you?
Every night. You don't see them as nagging doesn't work at all (the
one from Sam's machine) as nightly Gumps are broken, currently. Maybe
I should publish my nightly results until Sam's builds are up again.
But then again, you should be able to see the failures un
gump.covalent.net as well.
> If you are running latest Ant,
You are joking, right? ;-)
Sometimes it is more recent than CVS HEAD.
Stefan
GUI/Stats/Gumping stuff (was Stefan's comments)
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> The single most important feature for me is that it can run at night
> from cron with nobody around - and I love the timeout feature at least
> available on Linux that can kill hanging Axis or Cactus or
> Tomcat-Connector builds.
I have the same use case, and I thought I wouldn't like the GUI. Then I
tried it, and I really liked the way it allowed my to introspect the
metadata. I think there is great potential there. Again, I will likely never
run builds from the GUI, but I like the options it provides for tools for
basic users. I'd like to see the GUI (1) have a wizard for creating new
project metadata (2) allow "create me a profile that would build me X,Y and
Z from bottom up -- no extras". About 6 months ago I would've paid money (a
dirty set of words ;-) for (2).
Ok, where on earth is this timeout feature? I want it also, but I don't know
where to find it. Can you point me to it? Thanks.
> There may be a language problem here, I'm not sure. "concerned" was
> supposed have a negative connotation when I wrote it, sorry.
Nah, I probably just interpretted via what I wanted to read. Yes, there is
the potential for negative, but I'd like to have more faith in the
community, that they'd be used for posotive. If they happen, then time will
tell.
Statistics are not the goal, so sure -- fix things for other folks. If you
fix problems, you are part of the community. However, I was talking
primarily about code bugs (like one that has huanted me w/ VFS/HttpClient
for the last month).
Primarily, I think component re-use suffers from lack of trust amongst
developers. I beleive that many developers don't like to rely upon others,
so don't re-use if they can avoid it, I've seen it even on Jakarta. With
commons/sandbox and even incubator I feel there is the chance for lots of
non-cooperating projects, and I don't like that. I am not naive enough to
think that all software can/ought work together, but I'd like to see Gump
help shift the balance. [BTW: My interest in http://krysalis.org/version is
because I use stacks of code, and want it to work together, so maybe this is
my personal use case/bias.]
As such, I think statistics are mainly a good things for good projects, and
a gentle nudge for others.
> Very unlikely, even for projects that consider themselves "friends of
> Gump". When has Gump tried to build Cocoon or Forrest the last time?
But shouldn't it? Couldn't it? Why not - resources? complexity?
> Are you aware that almost all krysalis-* projects fail every night
> "because Centipede has not been not initialized"? 8-)
No, not at all. I monitor them, as do others, and they work. I've not seen
nags to this effect, have you?
We have some issues w/ tests projects right now, but in the main they work,
see Nick's custom gump:
http://gump.chalko.com/
So, is this centipede problem an environmental one on your system, or your
stack? Could you send me more information to help track it down? If you are
running latest Ant, and ant is about to be released, and centipede is
failing ... Krysalis folks really need to know, thanks.
regards,
Adam
Re: Stefan's comments on Gumpy ( was Re: Sanity Check & Gump Community [please read/respond] )
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 26 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:
> A +0 at best,
which means "yes, but I won't/can't help".
There have quite been a few people on this list who apreciated a
Python rewrite a few months ago and I've never been among them. Just
wait for the others to chime in. 8-)
> The Python Gump code is pretty simple, but still takes some time. I
> can understand that this is a barrier to entry for a lot of Java
> programers.
Just to be clear, Java is by far not the first language I've learned
(Sinclair's dialect of Basic IIRC ;-) and it certainly won't be the
last. I don't need Python for any other stuff I work on (neither for
fun nor for money) and current Gump matches all my needs. I simply
don't have any reason to learn Python - and even less time.
> As it stands it does the core
The single most important feature for me is that it can run at night
from cron with nobody around - and I love the timeout feature at least
available on Linux that can kill hanging Axis or Cactus or
Tomcat-Connector builds.
I'm pretty much a no-GUI guy, so a nifty GUI won't buy me.
> 1) It doesn't process outputs (copying jars somewhere, publishing
> javadocs, publishing junit).
Yes, this has become an important side effect.
> 2) It doesn't process projects on workspaces only on modules.
I have two extra <module>s in my workspace and a project override for
the "gump" project itself (to add some deliver tags). It is important
to me but not vital.
> 3) It doesn't handle depends on ant tasks (keep meanign to ask you
> Stefan, 'cos I've seen you use it, what is that?)
I have no idea what you are talking about, sorry.
Maybe
<ant>
<depend project="..." .../>
</ant>
Take a look here <http://jakarta.apache.org/gump/ant.html#depend>.
>> > *Python Gump using Forrest
>>
>> I don't care at all, honestly.
>
> Do you run Gump personally/locally,
Yes. Via cron every night. And sometimes manually when I want to
test a bigger change to Ant.
> or do you run local custom Gumps?
Basically the default profile plus two extra modules.
> In short -- do you run it remotely and have it communicate to you
> via HTML(/RSS)?
It communicates to me via email. <nag to="my-address/> in my
workspace. I only seldomly look at the generated HTML output, I have
never looked at the RSS output. Thus I really can't be bothered how
the output gets generated.
> Do you want HTML output
Yes.
> (whether it is forrest or XYZ that helps produce it?)
Exactly 8-)
I don't care how it is produced.
>> > *Gump Statistics (as a tool for automatically communicating
>> > reuse/reliability/robustness, etc.)
>>
>> Depends on the kind of statistics. I'm really concerned about
>> reliability/robustness values computed from Gump failures.
>
> Ah, really really? Cool, do I have something to entice you?
There may be a language problem here, I'm not sure. "concerned" was
supposed have a negative connotation when I wrote it, sorry.
> I'd like statistics to show "responsiveness" (to problems).
This is a type of statistics I'd be most afraid of.
Build of project A fails because they've added a new dependency and
failed to update their descriptor. I see it first because my
nightlies start a few hours before Sam's. Do I go ahead and fix the
failure or do I keep away from fixing it to not dilute the statistics?
Do I keep away from fixing it for weeks to show how unresponsive a
project team is?
I wouldn't appreciate any automated finger-pointing either.
> BTW: What bugs me is if product X changes it's API (or fails to run
> unit tests) and hence breaks innocent product Y, then Y gets the bad
> mark. If X is then stagnant/unresponsive, Y gets slammed. I don't
> see a way that Gump can detect it was X that broke Y, and not Z. Now
> I realize that Y will eventually move off X,
Very unlikely, even for projects that consider themselves "friends of
Gump". When has Gump tried to build Cocoon or Forrest the last time?
Are you aware that almost all krysalis-* projects fail every night
"because Centipede has not been not initialized"? 8-)
>> > *Distributed Gump Trees (also using Ruper to download upstream
>> > Gump outputs)
>
> If I could automatically (via Ruper) download last night's Gump'd
> outputs from Jakarta, then I'd be "in pretty good shape"
OK, I see. Yes, having a tool that spiders
http://gump.covalent.net/jars/latest/ and put the jars in place for
your installed modules would help.
> Ok, so the flip side. What say folks did this, and the main gump
> became a 15+ hour build.
We've been close to that already. When sourceforge's CVS was really
really slow, I mean, even slower than right now.
> Would you stop running Gump, and use rsynch/Ruper/other to get jars
> from public?
No.
> Would this be bad for you?
Extremely.
> (I guess I don't know what do you use Gump for.
A regression test environment for Ant - mostly. And as such I have to
build everything. I understand that I'm in an almost unique position
here.
Stefan
Stefan's comments on Gumpy ( was Re: Sanity Check & Gump Community [please read/respond] )
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
I really want answers from everybody, if at all possible, but even Stefan's
responses are enlightening. A +0 at best, almost a -1. Interesting, I wanted
a sanity check, maybe I'll get one here.
I guess I need to examine why would a rewite (forcing change) be wanted? I
think it needs to bring some things radically new. I (personally) have made
the effort to learn Python, and it took a while. The Python Gump code is
pretty simple, but still takes some time. I can understand that this is a
barrier to entry for a lot of Java programers.
> > *Python Gump (as a future replacement for traditional Gump)
>
> +0 as long as it can do everything that the "traditional" Gump can.
> -1 otherwise.
As it stands it does the core (as I understand it) yet it fails to cope with
a few things, and I was hoping to make it
1) It doesn't process outputs (copying jars somewhere, publishing javadocs,
publishing junit). This is towards the top of my TODO.
2) It doesn't process projects on workspaces only on modules.
3) It doesn't handle depends on ant tasks (keep meanign to ask you Stefan,
'cos I've seen you use it, what is that?)
4) I am sure there are some other subtle differences.
Otherwise, I feel it does everything and more. (1) I will fix, but I'm not
sure about (2) or (3) [partly 'cos I don't see understand them.]
The more:
1) [IMNSHO] Easier development entry (even for Java programmers, XSLT isn't
Java).
1) A GUI (there are lots of benefits here, some really nice ws/profile
visualizations.)
2) Better "check tools", better debugging, and other tools.
3) Statistics, the sky is the limit. (especially if we write to some
database, I'm using DBM right now.)
4) Cleaner extension points can be added (for users, like me, who use Gump
to do more than just build, but publish/other from inside gump's projects).
5) Easier personalized installation ... daft, but true IMHO. The pain is in
the ws/profile configuration, and Python Gump helps the users get inside it
easier.
6) More OO (if far from perfect) and open for extension/customization.
> I won't find the time to learn enough Python to jump into coding so I
> can't be +1. I've already had my share of code contributions to the
> "traditional" Gump and expect to keep supporting it.
This I'll leave until the future.
> > *Python Gump using Forrest
>
> I don't care at all, honestly.
Do you run Gump personally/locally, or do you run local custom Gumps? In
short -- do you run it remotely and have it communicate to you via
HTML(/RSS)? Do you want HTML output (whether it is forrest or XYZ that helps
produce it?)
> > *Gump Statistics (as a tool for automatically communicating
> > reuse/reliability/robustness, etc.)
>
> Depends on the kind of statistics. I'm really concerned about
> reliability/robustness values computed from Gump failures.
Ah, really really? Cool, do I have something to entice you? I think
statistics (along with easier debugging) are what drove me to want a new
Gump (or one I could understand/maintain). I agree 100% that
reliability/robustness values are needed.
Are you game to help me with thoughts on what these ought be, and how to
determine them, and algorythms for them? I consider this a key constribution
Gump can make to OSS, a dispassionate view of a project for folks to
consider in order to make "build verse buy" (i.e. re-use) decisions. If
there were two choices, perhaps to help them pick one that has reached
greater maturity.
I'd also like statistics to show "activity" (at CVS level I guess). I'd like
statistics to show "responsiveness" (to problems). FOG Factor is simple
"successes - (failures + prereq failures)", but it might be ok (over time).
I recall the archives having a richer algorythm, but I think this one is an
adequate start.
BTW: What bugs me is if product X changes it's API (or fails to run unit
tests) and hence breaks innocent product Y, then Y gets the bad mark. If X
is then stagnant/unresponsive, Y gets slammed. I don't see a way that Gump
can detect it was X that broke Y, and not Z. Now I realize that Y will
eventually move off X, but that fact won't be captured in stats, which is a
shame. Still, I feel better some information than no information, we can
improve/mature it over time.
And, oh yeah, I consider statistics as subversive marketing for good
products. ;-) ;-)
> > *Gump and Ruper (using Ruper to download packages)
>
> I'm not sure whether Ruper can help a lot when many of the installed
> packages require you to click through a license.
Good point, noted.
But what of the outputs of Gump that are redistributable.
> > *Distributed Gump Trees (also using Ruper to download upstream Gump
> > outputs)
I run Gump on my stuff, but I have to build much of Jakarta first, and that
is tough on my limited resources. If I could automatically (via Ruper)
download last night's Gump'd outputs from Jakarta, then I'd be "in pretty
good shape" for less. Say I did this, and produced my own outputs. Say
others fed of my repository and/or Jakartas, and on. A tree of nested gumps.
> > *Gump Documenter (as a tool for communicating the OSS map, and
> > promoting)
Mapping out the dependencies in the OSS world, to document it. Showing
dependencies, dependees ... perhaps showing history of this. I think there
is extreme value in the project descriptors (I'm sure you agree here, you
invest so much time in them) and I think we need to slice/dice that metadata
to present it to humans for perrusal.
> I don't think I understand these 8-)
>
> > *Promoting more gump projects in public Gump (do resources exist,
> > will the 7+++ hours grate on Stefan?)
> > *Promoting more public/private/personal Gumps.
> > *Promoting more OSS Gumps (e.g. on SF.net. on Java.net, etc.)
>
> Marketing has never been my business and will never be. +0.
Ok, so the flip side. What say folks did this, and the main gump became a
15+ hour build. How would you be affected? Would you stop running Gump, and
use rsynch/Ruper/other to get jars from public? Would this be bad for you?
(I guess I don't know what do you use Gump for. Do you gump your own private
projects?)
Thanks for your time/insights Stefan.
regards
Adam
Re: Sanity Check & Gump Community [please read/respond]
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 25 Sep 2003, Adam R. B. Jack <aj...@trysybase.com> wrote:
> *Python Gump (as a future replacement for traditional Gump)
+0 as long as it can do everything that the "traditional" Gump can.
-1 otherwise.
I won't find the time to learn enough Python to jump into coding so I
can't be +1. I've already had my share of code contributions to the
"traditional" Gump and expect to keep supporting it.
> *Python Gump using Forrest
I don't care at all, honestly.
> *Gump Statistics (as a tool for automatically communicating
> reuse/reliability/robustness, etc.)
Depends on the kind of statistics. I'm really concerned about
reliability/robustness values computed from Gump failures.
> *Gump and Ruper (using Ruper to download packages)
I'm not sure whether Ruper can help a lot when many of the installed
packages require you to click through a license.
> *Distributed Gump Trees (also using Ruper to download upstream Gump
> outputs)
> *Gump Documenter (as a tool for communicating the OSS map, and
> promoting)
I don't think I understand these 8-)
> *Promoting more gump projects in public Gump (do resources exist,
> will the 7+++ hours grate on Stefan?)
> *Promoting more public/private/personal Gumps.
> *Promoting more OSS Gumps (e.g. on SF.net. on Java.net, etc.)
Marketing has never been my business and will never be. +0.
Stefan
Re: Sanity Check & Gump Community [please read/respond]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Adam R. B. Jack wrote:
> I'd *really* appreciate feedback on these thoughts. If you only answer one
> mail from me, please make it this one.
Couldn't get my head to answer you till now, sorry for the delay. It's a
pity that your Gump itch does not come at a time when I itch too ;-)
> The topics are:
>
> 1) Sanity check on what I'm doing w/ Gump (or hoping to)
> 2) Internal Community
> 3) External community
>
...
>
> *Python Gump (as a future replacement for traditional Gump)
The way to go. +1
> *Python Gump using Forrest
Not technically necessary but I applaud the effort +1
> *Gump Statistics (as a tool for automatically communicating
> reuse/reliability/robustness, etc.)
Simply statistics, what they communicate is up to the reader ;-) +1
> *Gump and Ruper (using Ruper to download packages)
+1 Important for easy installation. I'd add that Gump *must* install
*hassle free*.
> *Distributed Gump Trees (also using Ruper to download upstream Gump outputs)
Doh, you lost me here.
> *Gump Documenter (as a tool for communicating the OSS map, and promoting)
Interesting.
> *Promoting more gump projects in public Gump (do resources exist, will the
> 7+++ hours grate on Stefan?)
+1 as long as there are tools that help maintainers get the things fixed
fast.
> *Promoting more public/private/personal Gumps.
Private Gumps especially.
> *Promoting more OSS Gumps (e.g. on SF.net. on Java.net, etc.)
COuld be interesting :-)
> Questions: Anybody got any other itches they'd like to see scratched by
> Gump? I'm not volunteering, per se, just curious.
Integration with Eclipse.
> Second, internal community:
>
...
> Is there a way we can make a concerted effort to
> promote Gump, and request developers? Thoughts?
The same thing I've told you for the Krysalis projects: release.
We gotta make something that all developers can use. Gump *is*
incredible value, but we *must* release and make others use it.
I'll try to "install" it as a novice user and tell you where I get
stuck, so we can work out the problems. As soon as I can install it
without resorting to the manual more than once, we can so a milestone
release, and from then on the ride starts.
> Third, external community:
>
> External community is key, and I see Gump as closed to those 300 or so
> modules it supports. Ought we propose a Gump on SF.net, or on java.net, or
> wherever? I think Gump's strengths are best felt with a large profile, so
> much as the GUI Gump is cool, I think big public Gumps are invaluable. Has
> anybody suggested a Gump on SF.net to SF.net, to others? Now that Gump is
> far easier to install (than when Andy Oliver tried) it really ought be
> possible for folks to have their own. Is this a good thing for future Gump?
I see Gump, I mean "The" Gump, as the Apache runs. Then I see developers
using it on their machines to run the projects they have in the workspace.
Scenario: I have projects from CVS in a directory. I have a jar
repository location. I download Gump, tell him where my workspace is,
and it autoconfigures itself. Then I am able to use it fully to compile
projects with dependencies resolved, and have it output reports.
When we get here, we have *the* cross-project buildtool.
> What do folks think about Gump's future, about what it ought be trying to
> be, about who it ought be targeted at?
- Stefan and Sam (not joking, they are the power-integration users)
- every developer
> Thanks in advance for all responses.
Thank you for working on it. You really impressed me (again). :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------