BATCH: All dressed up, with nowhere to go...
Dear Gumpmeisters, The following 8 nags should have been sent G U M P [EMAIL PROTECTED]: webwork/webwork failed [EMAIL PROTECTED]: freemarker/freemarker failed [EMAIL PROTECTED]: javasrc/javasrc failed [EMAIL PROTECTED]: jetty/jetty failed [EMAIL PROTECTED]: xml-xerces/xml-xerces1 failed [EMAIL PROTECTED]: eyebrowse/eyebrowse failed [EMAIL PROTECTED]: jrefactory/jrefactory failed [EMAIL PROTECTED]: jgen/jgen failed G U M P [EMAIL PROTECTED]: webwork/webwork failed To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://gump.apache.org/nagged.html, and/or contact [EMAIL PROTECTED] Project webwork has an issue affecting it's community integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state is 'Failed', for reason 'Build Failed' Full details are available at: http://lsd.student.utwente.nl/gump/webwork/webwork.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Error - Failed with reason build failed - - - - - -- -- G U M P Gump performed this work: Work Name: build_webwork_webwork (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 13 seconds Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true -Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/data3/gump/xml-xalan/java/build/xalan-unbundled.jar:/data3/gump/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/data3/gump/gump-install/work/merge.xml -Dbuild.sysclasspath=only [Working Directory: /data3/gump/webwork] - [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:69: cannot resolve symbol [javac] symbol : class MultipartListener [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartListener listener = new MultipartListener() [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:69: cannot resolve symbol [javac] symbol : class MultipartListener [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartListener listener = new MultipartListener() [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:92: cannot resolve symbol [javac] symbol : class MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] multi = new MultipartRequest(req.getContentType(), [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:96: cannot resolve symbol [javac] symbol : variable MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartRequest.IGNORE_FILES_IF_MAX_BYES_EXCEEDED, [javac]^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:102: cannot resolve symbol [javac] symbol : class MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] multi = new MultipartRequest(req.getContentType(), [javac] ^ [javac] /data3/gump/webwork/src/main/webwork/multipart/WebworkMultiPartRequest.java:107: cannot resolve symbol [javac] symbol : variable MultipartRequest [javac] location: class webwork.multipart.WebworkMultiPartRequest [javac] MultipartRequest.IGNORE_FILES_IF_MAX_BYES_EXCEEDED, [javac]^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 15 errors BUILD FAILED /data3/gump/webwork/build.xml:167: Compile failed; see the compiler error output for details. at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:944) at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:764) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:269) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:301) at org.apache.tools.ant.Target.performTasks(Target.java:328) at org.apache.tools.ant.Project.executeTarget(Project.java:1215) at org.apache.tools.ant.Project.executeTargets(Project.java:1063) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAn
[Gump Wiki] Updated: GumpPython
Date: 2004-03-08T21:57:21
Editor: 65.96.189.168 <>
Wiki: Gump Wiki
Page: GumpPython
URL: http://wiki.apache.org/gump/GumpPython
no comment
Change Log:
--
@@ -55,7 +55,7 @@
== Command Line Tools: Get Started with update.py and build.py ==
- * install 'regular' gump as per http://jakarta.apache.org/gump/usage.html
+ * install 'regular' gump as per http://gump.apache.org/traditional/usage.html
* install [http://www.activestate.com/Products/ActivePython/ Python 2.2]
* open a shell and do something similar to:
{{{
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Moving gump forward
Adam R. B. Jack wrote: Stefan Good topic, thanks for raising it, it is time. Me or Stefan? Gump is an incredible idea and has no equivalent thing anywhere else. Still, it requires lots of energy from the gumpmaisters to keep it running. [...] Gump social maintenance costs are still too high on the gumpmaisters and not well distributed horizontally across the various projects. Stefano, I concur with your observations, and like your proposals, but I think we (as a group) keep overlooking one main thing. Gump is a social experiment but we keep using the techie's golden hammer -- more technology -- to try to solve it. Making things easier for users who don't care about what we do is just going to make it easier for them not to care. ;-) I strongly disagree with this. In fact, it's largely the opposite: nagging them precisely will make them care. But from that point on, it's our responsibility to make their life easier in finding a resolution for the problem. This can be solved with a better gump system and better (higher S/N) data presentation. We have a social experiment, yet we've (so far) failed to exercise the social options. The Gump team know OSS, they know (as good as anybody) what drives folks, what motivates, what inspires. Even though we accept that nobody can engineer this, we can attempt to leverage it & work with it. Right after I posted to commons-dev about Gump, and it's aspirations to judging health, we had one gentleman go to the trouble of digging out the algorythm for FOG from Gumpy CVS, evaluating it, and submitting a JIRA entry (which I agree with, BTW). That is effort, that is motivation. The loss of "team pride" (maybe) of having their FOG factor halved was a motivator. I agree. FoG could be a big factor in creating the itch to scratch... but it could also be a potential killer if not considered "fair". And my experience says that no matter what heuristic, somebody won't like it if you are using it to judge them. I think Gump needs to get out there, go in-your-face public. Now that we are TLP we have a forum to get messages out (gump.apache.org) but we need to acquire traffic & work with existing public forums. We ought use community@ [or similar] and Peas-n-Carrots (& Planet Apache). I'm no marketeer, but I think we need to market Gump results -- not market Gump [although that might come], but the results. Some [RT] style ideas: - We need to post (weekly?) to community@ the top FOGs, top improvers and bottom FOGs. We need to be public about which projects are strong, which are upcoming, and which are failing w/o attention. It is fine to generate a WWW site of results, as we do, but we need to live-and-breath those results, make them reach out and touch people. I'd be +1 to this, but only when the list I see reflects the reality I perceive. Currently, the state of Gump shown by the figures is much better than the state of gump that *I* personally picture in my mind. Admittedly, with my cocoon bias, I'm a little frustrated because cocoon is by far the project with more dependencies, so it's the hardest to tackle, but exactly because of that, we can't state that gump has bootstrapped itself until we reach that point (and we did once in the past, but than the system failed to keep it up, for whatever reason) - We need to get to a point where Gump is the first place somebody comes in order to determine if they wish to use a new product/package. A conversation around "why would we introduce a product with a FOG of 0.1 when we are at 1.5?" ought be common. that would be cool, yes, but again, potentially very self-replicating: I mean, it's like the first-10 sourceforge effect: the popular ones become even more popular and the power-law slope increases... I'm not sure I want that. - We need to make FOG (or Gump score, whatever) an active thing. Perhaps PMCs ought evaluate FOG before allowing a project out of sandbox, out of incubation. [Note this is *RT*, not proposal]. If I know the foundation well enough, this is hardly ever going to happen, for the reasons I expressed above: no matter what heuristic you find, those who get a bad score and disagree with you will give you a very hard time. - I think we need a nice 'I rate with Gump' icon, that dynamically links to their score. [Before we do, we need the numbers to really mean something, and to take into consideration some key aspects -- depth of dependences, distance between two projects -- some Googlesque value of 'links to' (where teams are 'rating' each other through usage/referencing.) Gump stats are in their infancy, and not taking into consideration much of the value of the metadata graph. I think we ought add much more to it also, like 'friend of' (even if not a dependee). Maybe even add 'who associates with' (an individual aspect) -- so we can follow folks we like. I could go on and on and on ... and will w/ an [RT] sometime soon, I hope.] I totally agree that there is a goldmine of data in the dependency
Re: [RT] Moving gump forward
Adam R. B. Jack wrote: Leo wrote plenty -- with this just being a snippet: = The Human Factor = What I really like about gump is the principle that we emulate developer behaviour as much as possible. Yup, me too, I liked it when you posted to Avalon-Dev also. Maybe we need a logo of some crazied gung-ho half-blind half-carpel-tunneled geek who just can't see a CVS commit message they don't want to tinker with. ;-) The rest of what you wrote -- made me reconsider my last posting. I'm not saying that aspects of Gump aren't broken, and we need just promote, I just think we need to promote for those happily using Gump right now. For those with simple build systems things really aren't that that bad. I wonder if that is the majority or not. Adam, that's why I dislike those numbers so much: they give a false impression. Having 60% of the tree built is useless if that 40% is where the juice is. Where is the juice? where it is hardest to keep track of dependencies. Cocoon didn't have a single gump run in 6 months or more. Focus on fixing that and you'll see how thing change. That said, Gump is very sensetive to the build system, and I like the IDE comparison/analogy/proposal. Doing a build is a compile plus a jar (plus perhaps unit tests/others?). I'd like Stefan's input on if we allowed a BTW: I suspect that I think we should focus on using what the projects have. It's harder to start with, but much more solid in the longer run. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Moving gump forward
Leo Simons wrote: But since we're going by leaps and bounds right now...we need a wiki-style workflow. Ditch CVS and provide me with an "edit this descriptor" page. The task of finding the right descriptor to edit can be several minutes of work. That should change to several seconds. Leo: do you realize the potential security implications of this? = The Human Factor = What I really like about gump is the principle that we emulate developer behaviour as much as possible. We could just let the metadata point to the sources, do away with ant alltogether, and implement an IDE-like compiler. But then gump would be able to build lots of things that might fail to build on the commandline. yes, this is why I'm kinda reluctant to make gump more aware of what's going on internally. the fact that gump is dumb and proud to be is a lovely feature, IMO. = The friggin' broken buildsystem = It's not always a classfile change that broke things. In the avalon case, for example, the projects that are failing to build haven't seen very significant API change. The build itself is broken. Maybe we should fall back to trying a non-ant build when that happens. Is it possible to detect an ant (or maven) failure as opposed to an api change? Is it worthwhile to seperate it out. not unless we analyze the output. = Let's go relational = We want to build a complex, flexible, relational model of all these builds. Maybe its just me, but XML doesn't express that too well. It's much easier to express some fomrs of "intelligence" in SQL. My "let's go relational" was for the history data, not for the project descriptors. Going relational there would buy us only more effort (unless you write a web application to handle those things directly ;-) Enough brainstorming for tonight. I have more to say, but gotta run right now :-D keep it coming :-) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Moving gump forward
Daniel F. Savarese wrote: In message <[EMAIL PROTECTED]>, "Daniel F. Savarese " writes: Another heuristic approach that would work for Java projects at least, would be to analyze the build failure messages. Usually they'll reference a class or class member/method that is in a dependent code base. Develop an evolving library of patterns to extract the offending methods/classes/etc. and then discover what jar they came from. Right after I sent that I realized that there's a more effective variation of this idea. The compiler often knows exactly why a compile failed. It should be possible to extend one of the several Java compilers out there with some Gump-aware code that will map the package an offending programming construct belongs to back to the project it belongs to. That doesn't help you directly in the case when an API artifact is removed or renamed (although it does help when a method signature changes), but it does help you narrow down the change based on the packages imported by the file. So you can limit the scope of dependencies on which you apply the brute force comparative build approach. In fact, for Java code, instead of going to the trouble of enhancing the compiler, it may be enough just to look at the packages in the file(s) that failed to compile based on the error message spewed by the compiler. Maybe it's better to think about how a human goes through the process of tracking down the source of a failure and see how that can be emulated. Again, that's assuming that 100% accurate solutions are too computationally expensive to be practical. That's it for my RT contribution. I'm on EST. yep, I had the exact same thoughts about modifying a compiler, but as i said previously, I would love to think at language-agnostic ways to do this. this said, it would be just marvellous if gump could spot dependencies transparently by analzying the classloading patterns of the compiler. that would allow gump to suggests improvements to the various gump descriptors automagically. but this modification is not easy, given that we need to change ant for this. Stefan, any talks in ant-land about using eclipse JTD compiler instead of javac for the task? or, eventually, how can gump execute ant forcing the task to be our own? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Moving gump forward
Daniel F. Savarese wrote: In message <[EMAIL PROTECTED]>, Stefano Mazzocchi writes: Now, I think it's possible (even if computationally expensive) to understand exactly what commit broke the build and to nag the exact person and the community and copy all the offended people. ... for those not familiar with exponential growth, it's enough to say that if the build took a minute it would take gump 2,5 billion years to find out what broke the build. Why don't you start with the easy stuff. If a build of project A fails, we know all builds depending on project A will fail. But if project A is dependent on project B, and project B failed, then we keep on walking up the tree to find the first build that failed. Okay, so now that leaves the issue of a build failing because of an API or some other change in a dependent project that built successfully. For projects with a small number of dependencies, use the brute force approach you described. For projects with a large number dependencies, develop some heuristics. Yes, I was thinking about this today. You can reason that if project B makes a change that breaks project A and if C also depends on project B, then there's a chance project C might also have broken. uh, that's a brilliant suggestion right there! Since Gump builds a ton of code bases, a decent number of culprits (i.e., project B) could be identified by analyzing the dependencies shared by projects that failed to build. This is awesome! I love it! You can then apply the brute force approach to only those shared dependencies if they number below some manageable figure. Sweet! Another heuristic approach that would work for Java projects at least, would be to analyze the build failure messages. Usually they'll reference a class or class member/method that is in a dependent code base. Develop an evolving library of patterns to extract the offending methods/classes/etc. and then discover what jar they came from. yes, I was going to suggest this approach next, but I'm reluctant because I deeply appreciate the fact that gump is language agnostic and it should remain the same, IMO. Anyway, those are some inelegant, inxact, and simplistic--but perhaps useful in some instances--suggestions about how to start adding the functionality you describe that would buy time to figure out how to do it right. yep That is, assuming it's a hard problem that requires a good while to figure out. My reasoning is that it's okay to nag the wrong projects every once in a while as long as you nag the right projects most of the time. And on first glance, based on your comments, it seems easier to implement that than to figure out the right project to nag all the time. yours are precious suggestions. many thanks for taking the time to share them. I'll try to think more about heuristics on broken dependencies and report back. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
cvs commit: gump/python/gump engine.py
ajack 2004/03/08 16:20:51
Modified:python/gump engine.py
Log:
Display package listings even if no license (indent problem)
Revision ChangesPath
1.77 +15 -21gump/python/gump/engine.py
Index: engine.py
===
RCS file: /home/cvs/gump/python/gump/engine.py,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- engine.py 8 Mar 2004 22:28:08 - 1.76
+++ engine.py 9 Mar 2004 00:20:51 - 1.77
@@ -766,25 +766,20 @@
# directories
outputs.append(licensePath)
-#
-# List all directories that should've contained
-# outputs, to see what is there.
-#
-dirs=[]
-dircnt=0
-listed=0
-for output in outputs:
-dir=os.path.dirname(output)
-if not dir in dirs:
-dircnt += 1
-if os.path.exists(dir):
-listDirectoryToFileHolder(project,dir,\
-FILE_TYPE_PACKAGE,
-
'list_'+project.getName()+'_dir'+str(dircnt)+'_'+os.path.basename(dir))
-dirs.append(dir)
-listed += 1
-else:
-project.addError("No such directory (where package
output is expected) : " + dir)
+#
+# List all directories that should've contained
+# outputs, to see what is there.
+#
+dirs=[]
+dircnt=0
+for output in outputs:
+dir=os.path.dirname(output)
+if not dir in dirs:
+dircnt += 1
+listDirectoryToFileHolder(project,dir,\
+FILE_TYPE_PACKAGE,
+
'list_'+project.getName()+'_dir'+str(dircnt)+'_'+os.path.basename(dir))
+dirs.append(dir)
"""
@@ -826,8 +821,7 @@
#
# Load stats (and stash onto projects)
#
-db.loadStatistics(workspace)
-
+db.loadStatistics(workspace)
"""
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Moving gump forward
2) we must make sure that people's nagged uncomfort grows with the amount of dependecies they break! Note that giving them a number doesn't work, you have to build up the entire list!!! you have to make them feel really uncomfortable. The more uncomfortable, the more energy they are going to push into the system to keep this from happening!!! or the faster they are going to resolve an issue that emerges!! this increased obnoxiousness of nagging must also result in better web pages, because, after we push them to tackle the problem, at this point, we want to help them figuring out what's wrong and what they can do to fix it. So, scenario of use is: [snip] If Gump knows what dependancies a particular project has, when the project and each of its dependencies last built successfully and it knows how to get the source from CVS, it should be possible to list all the CVS changes that have happened since the last successful build. Of course, if each gump installation also knows of other gump installations including the JRE, it might be possible to further reduce the list of changes by sharing results between gumps. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/python/storage/results resulter.py
ajack 2004/03/08 14:28:09 Modified:python/gump/test gumpset_tests.py python/gump check.py update.py gumprun.py engine.py build.py continuous.py integrate.py python/gump/document forrest.py text.py python/gump/results resulter.py python/gump/storage gen.py python/gump/utils http.py commandLine.py python/gump/output nag.py python/gump/gui view.py python/gump/model loader.py python/storage/results resulter.py Log: 1) Make GumpSet have modules/moduleSequence to match projects/projectSequence, not just modules. 2) Reworked command line (a hack) to allow it to set GumpRunOptions 3) Try making the commandline scripts a little more friendly to adhoc usage Revision ChangesPath 1.5 +4 -4 gump/python/gump/test/gumpset_tests.py Index: gumpset_tests.py === RCS file: /home/cvs/gump/python/gump/test/gumpset_tests.py,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- gumpset_tests.py 17 Feb 2004 21:54:21 - 1.4 +++ gumpset_tests.py 8 Mar 2004 22:28:08 - 1.5 @@ -87,7 +87,7 @@ for p in projects: print " Project : " + p.getName() - sequence=gumpSet.getSequence() + sequence=gumpSet.getProjectSequence() print "Project Sequence:" + str(len(sequence)) for p in sequence: print " Sequence: " + p.getName() 1.38 +5 -9 gump/python/gump/check.py Index: check.py === RCS file: /home/cvs/gump/python/gump/check.py,v retrieving revision 1.37 retrieving revision 1.38 diff -u -r1.37 -r1.38 --- check.py 2 Mar 2004 21:11:39 - 1.37 +++ check.py 8 Mar 2004 22:28:08 - 1.38 @@ -92,16 +92,12 @@ if __name__=='__main__': # Process command line -args = handleArgv(sys.argv) +(args,options) = handleArgv(sys.argv) ws=args[0] ps=args[1] # get parsed workspace definition -workspace=WorkspaceLoader().load(ws) - - -# TODO populate... -options=GumpRunOptions() +workspace=WorkspaceLoader().load(ws, options.isQuick()) # The Run Details... run=GumpRun(workspace,ps,options) 1.23 +2 -5 gump/python/gump/update.py Index: update.py === RCS file: /home/cvs/gump/python/gump/update.py,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- update.py 24 Nov 2003 18:32:19 - 1.22 +++ update.py 8 Mar 2004 22:28:08 - 1.23 @@ -37,12 +37,12 @@ if __name__=='__main__': # Process command line -args = handleArgv(sys.argv) +(args,options) = handleArgv(sys.argv) ws=args[0] ps=args[1] # get parsed workspace definition -workspace=WorkspaceLoader().load(ws) +workspace=WorkspaceLoader().load(ws, options.isQuick()) # # Check Environment (eventually not do this each time) @@ -56,9 +56,6 @@ # to screen. # #check(workspace, ps, context, 0) - -# TODO populate... -options=GumpRunOptions() # The Run Details... run=GumpRun(workspace,ps,options) 1.10 +46 -11gump/python/gump/gumprun.py Index: gumprun.py === RCS file: /home/cvs/gump/python/gump/gumprun.py,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- gumprun.py3 Mar 2004 00:49:52 - 1.9 +++ gumprun.py8 Mar 2004 22:28:08 - 1.10 @@ -46,8 +46,9 @@ """ Contains the primary works sets -- to save recalculating and passing so many individual things around """ def __init__(self, workspace, pexpr=None, \ -projects=None, sequence=None, \ -modules=None, repositories=None ): +projects=None, projectSequence=None, \ +modules=None, moduleSequence=None, \ +repositories=None ): self.workspace=workspace if not self.workspace: raise RuntimeError, 'A non-None workspace is require' @@ -67,24 +68,32 @@ # # Project Build Sequence # -if not sequence: -self.sequence=self.getBuildSequenceForProjects(self.projects) +if not projectSequence: +self.projectSequence=self.getBuildSequenceForProjects(self.projects) else: -self.sequence=sequence +self.projectSequence=projec
cvs commit: gump/profile gump.xml
leosimons2004/03/08 13:57:22 Modified:profile gump.xml Log: Jicarilla has a few dependencies which are not built by gump. Let's build against some infamous jars-in-cvs until we get this sorted out. Revision ChangesPath 1.318 +1 -0 gump/profile/gump.xml Index: gump.xml === RCS file: /home/cvs/gump/profile/gump.xml,v retrieving revision 1.317 retrieving revision 1.318 diff -u -r1.317 -r1.318 --- gump.xml 4 Mar 2004 13:12:12 - 1.317 +++ gump.xml 8 Mar 2004 21:57:22 - 1.318 @@ -232,6 +232,7 @@ http://cvs.sourceforge.net/viewcvs.py/*checkout*/jicarilla/jicarilla-sandbox/platform/gump/gump-module.xml?content-type=text/xml&rev=HEAD"/> + http://cvs.sourceforge.net/viewcvs.py/*checkout*/jicarilla/jicarilla-maven-repository/gump-module.xml?content-type=text/xml&rev=HEAD"/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Moving gump forward
In message <[EMAIL PROTECTED]>, "Adam R. B. Jack" writes: >judging health, we had one gentleman go to the trouble of digging out the >algorythm for FOG from Gumpy CVS, evaluating it, and submitting a JIRA entry >(which I agree with, BTW). That is effort, that is motivation. The loss of >"team pride" (maybe) of having their FOG factor halved was a motivator. I had actually written a couple aborted emails (parts of which I cut and pasted into the improvement issue report) about the topic over preceding months that I never sent to the list because they sounded like I was making mountains out of mole hills and adding unnecessary noise when Gump committers were hard at work making more important improvements. I'm sure I sent a poorly articulated email about it around the time FOG was first added to the generated results. At any rate, it's been on my mind for a while since I believe it's inevitable lots of folks are going to pay attention to Gump because it's so handy. The FOG factor halving just reminded me of the topic and gave me a concrete example of why it can be misleading. >think we (as a group) keep overlooking one main thing. Gump is a social >experiment but we keep using the techie's golden hammer -- more >technology -- to try to solve it. ... >In summary -- my point is we've not explored the social solutions to the >Gumpmeister headache, and I'd love to hear other ideas on how we could >leverage that. I agree with what you said. If everyone is paying attention to Gump, then it matters little if you can't pin down exactly who's responsible for a failure because everyone who gets a nag works toward identifying the nature of the problem and coordinates with other projects to resolve the problem. Ultimately, Gump fosters cross-project cooperation. >Perhaps we ought copy 'affected' projects on nags, so the recipient & >those affected know who is affecting them. Nags are (right now) too >personal/private & a team can quietly sit on them. I think that would be very useful, but it could be limited in some way so that code bases used by hundreds of projects (e.g., parts of commons) don't generate hundreds of nags. Perhaps affected projects would receive an abbreviated email and another one after the problem is resolved. Also, you don't want a cascade of emails going out because of failures in multiple code bases and affected projects. So maybe a summary nag could go out to each project, tailored to that project. The summary would list all failures in code bases that depend on the project and all failures in code bases depended on by the project. Actually for the "depended on" code bases, it's probably better to list all dependencies and success or failure status of each because a code base can cause a failure in a project and still have built successfully. These customized failure summaries would avoid the need to automatically determine the exact source of a failure and whom to nag because it presents humans with a list of possible places to start hunting. Only if everybody ignores the emails does it fail to provide any benefit. If a small group of projects take an active interest, their connections to other projects should propagate responsiveness in general over time. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project smartfrog.xml
ajack 2004/03/08 11:32:23 Modified:project smartfrog.xml Log: Trying a different CVS set-up, for testing. Revision ChangesPath 1.15 +1 -1 gump/project/smartfrog.xml Index: smartfrog.xml === RCS file: /home/cvs/gump/project/smartfrog.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- smartfrog.xml 7 Mar 2004 19:49:12 - 1.14 +++ smartfrog.xml 8 Mar 2004 19:32:23 - 1.15 @@ -23,7 +23,7 @@ + dir="smartfrog" module="core"/> org.smartfrog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-jmeter.xml
sebb2004/03/08 10:39:22 Modified:project jakarta-jmeter.xml Log: Still trying to get rid of zip files from the classpath Revision ChangesPath 1.77 +6 -6 gump/project/jakarta-jmeter.xml Index: jakarta-jmeter.xml === RCS file: /home/cvs/gump/project/jakarta-jmeter.xml,v retrieving revision 1.76 retrieving revision 1.77 diff -u -r1.76 -r1.77 --- jakarta-jmeter.xml5 Mar 2004 10:57:48 - 1.76 +++ jakarta-jmeter.xml8 Mar 2004 18:39:22 - 1.77 @@ -173,7 +173,7 @@ - + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Moving gump forward
Leo wrote plenty -- with this just being a snippet: > = The Human Factor = > > What I really like about gump is the principle that we emulate developer > behaviour as much as possible. > Yup, me too, I liked it when you posted to Avalon-Dev also. Maybe we need a logo of some crazied gung-ho half-blind half-carpel-tunneled geek who just can't see a CVS commit message they don't want to tinker with. ;-) The rest of what you wrote -- made me reconsider my last posting. I'm not saying that aspects of Gump aren't broken, and we need just promote, I just think we need to promote for those happily using Gump right now. For those with simple build systems things really aren't that that bad. I wonder if that is the majority or not. That said, Gump is very sensetive to the build system, and I like the IDE comparison/analogy/proposal. Doing a build is a compile plus a jar (plus perhaps unit tests/others?). I'd like Stefan's input on if we allowed a
[Gump Wiki] New: HistoricalResultsDatabase
Date: 2004-03-08T08:22:26 Editor: AdamJack <[EMAIL PROTECTED]> Wiki: Gump Wiki Page: HistoricalResultsDatabase URL: http://wiki.apache.org/gump/HistoricalResultsDatabase no comment New Page: = HistoricalResultsDatabase = "'NOTE: WORK IN PROGRESS'" = Requirements = * Needs to be supported/supportable/available by [EMAIL PROTECTED] * Needs to be accessible by Python 2.2 * Needs to be able to store 1 year or more of data (more?) * Needs to be resilient over time (changing in projects/metadata) = Assumptions = * This will be an RDBMS repository = Issues = = Schema = = Proposal #1: MySQL database = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] Updated: FrontPage
Date: 2004-03-08T08:10:50 Editor: AdamJack <[EMAIL PROTECTED]> Wiki: Gump Wiki Page: FrontPage URL: http://wiki.apache.org/gump/FrontPage no comment Change Log: -- @@ -10,6 +10,10 @@ * GumpInternals * GumpScripts += Design Topics = + + * HistoricalResultsDatabase + = 'Special' Wiki pages = '''TitleIndex''' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/python/gump/document forrest.py
ajack 2004/03/08 08:04:09
Modified:python/gump/document forrest.py
Log:
We are showing dependees not dependencies
Revision ChangesPath
1.95 +4 -4 gump/python/gump/document/forrest.py
Index: forrest.py
===
RCS file: /home/cvs/gump/python/gump/document/forrest.py,v
retrieving revision 1.94
retrieving revision 1.95
diff -u -r1.94 -r1.95
--- forrest.py8 Mar 2004 05:40:50 - 1.94
+++ forrest.py8 Mar 2004 16:04:08 - 1.95
@@ -504,7 +504,7 @@
projectsSection=document.createSection('Projects with issues...')
projectsTable=projectsSection.createTable(['Name','Affected',\
-'Dependencies', \
+'Dependees', \
'Duration\nin state','Project State'])
pcount=0
for project in sortedProjectList:
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Moving gump forward
Stefan Good topic, thanks for raising it, it is time. > Gump is an incredible idea and has no equivalent thing anywhere else. > Still, it requires lots of energy from the gumpmaisters to keep it running. > [...] >Gump social maintenance costs are still too high on the gumpmaisters > and not well distributed horizontally across the various projects. Stefano, I concur with your observations, and like your proposals, but I think we (as a group) keep overlooking one main thing. Gump is a social experiment but we keep using the techie's golden hammer -- more technology -- to try to solve it. Making things easier for users who don't care about what we do is just going to make it easier for them not to care. ;-) We have a social experiment, yet we've (so far) failed to exercise the social options. The Gump team know OSS, they know (as good as anybody) what drives folks, what motivates, what inspires. Even though we accept that nobody can engineer this, we can attempt to leverage it & work with it. Right after I posted to commons-dev about Gump, and it's aspirations to judging health, we had one gentleman go to the trouble of digging out the algorythm for FOG from Gumpy CVS, evaluating it, and submitting a JIRA entry (which I agree with, BTW). That is effort, that is motivation. The loss of "team pride" (maybe) of having their FOG factor halved was a motivator. I think Gump needs to get out there, go in-your-face public. Now that we are TLP we have a forum to get messages out (gump.apache.org) but we need to acquire traffic & work with existing public forums. We ought use community@ [or similar] and Peas-n-Carrots (& Planet Apache). I'm no marketeer, but I think we need to market Gump results -- not market Gump [although that might come], but the results. Some [RT] style ideas: - We need to post (weekly?) to community@ the top FOGs, top improvers and bottom FOGs. We need to be public about which projects are strong, which are upcoming, and which are failing w/o attention. It is fine to generate a WWW site of results, as we do, but we need to live-and-breath those results, make them reach out and touch people. - We need to get to a point where Gump is the first place somebody comes in order to determine if they wish to use a new product/package. A conversation around "why would we introduce a product with a FOG of 0.1 when we are at 1.5?" ought be common. - We need to make FOG (or Gump score, whatever) an active thing. Perhaps PMCs ought evaluate FOG before allowing a project out of sandbox, out of incubation. [Note this is *RT*, not proposal]. - I think we need a nice 'I rate with Gump' icon, that dynamically links to their score. [Before we do, we need the numbers to really mean something, and to take into consideration some key aspects -- depth of dependences, distance between two projects -- some Googlesque value of 'links to' (where teams are 'rating' each other through usage/referencing.) Gump stats are in their infancy, and not taking into consideration much of the value of the metadata graph. I think we ought add much more to it also, like 'friend of' (even if not a dependee). Maybe even add 'who associates with' (an individual aspect) -- so we can follow folks we like. I could go on and on and on ... and will w/ an [RT] sometime soon, I hope.] Along the lines of what Stefano said, but adding a little to the social aspect: - Perhaps we ought copy 'affected' projects on nags, so the recipient & those affected know who is affecting them. Nags are (right now) too personal/private & a team can quietly sit on them. [This said, I think we want to push the positives -- values of success -- not try nagging folks into action.] - Perhaps we 'nag' folks when their FOG goes up into the next level (a positive :-) and also when it drops down to another level. Yes, as Stefano said, we ought (occasionally) let folks know their status even if things are status quo. In summary -- my point is we've not explored the social solutions to the Gumpmeister headache, and I'd love to hear other ideas on how we could leverage that. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/src/documentation/content/xdocs index.xml
bodewig 2004/03/08 06:27:45 Modified:src/documentation/content/xdocs index.xml Log: Throw in some additional info about Gump installations Revision ChangesPath 1.8 +3 -3 gump/src/documentation/content/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/gump/src/documentation/content/xdocs/index.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- index.xml 8 Mar 2004 14:09:28 - 1.7 +++ index.xml 8 Mar 2004 14:27:45 - 1.8 @@ -148,13 +148,13 @@ http://gump.covalent.net/log/index.html";>Covalent - - +1.4.0_00-b05 +Traditional Gump http://gump.cocoondev.org/";>CocoonDev - +Traditional Gump http://lsd.student.utwente.nl/gump/";>LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/src/documentation/content/xdocs/python usage.xml
On 8 Mar 2004, <[EMAIL PROTECTED]> wrote: > Add a mailing list page, Note that the (un)subscribe links are broken since forrest tries to obfuscate the email addresses. Is there any way to selectively turn off obfuscation here? Not that I'd mind turning it off completely as it doesn't help anyway. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/src/documentation/content/xdocs/python usage.xml
bodewig 2004/03/08 06:09:29 Modified:src/documentation/content/xdocs index.xml site.xml src/documentation/content/xdocs/python usage.xml Added: src/documentation/content/xdocs mail.xml Log: Add a mailing list page, fix references to jakarta-gump Revision ChangesPath 1.7 +1 -1 gump/src/documentation/content/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/gump/src/documentation/content/xdocs/index.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- index.xml 4 Mar 2004 17:26:10 - 1.6 +++ index.xml 8 Mar 2004 14:09:28 - 1.7 @@ -112,7 +112,7 @@ Where is Gump? - http://cvs.apache.org/viewcvs/jakarta-gump/";>Source + http://cvs.apache.org/viewcvs/gump/";>Source 1.11 +1 -4 gump/src/documentation/content/xdocs/site.xml Index: site.xml === RCS file: /home/cvs/gump/src/documentation/content/xdocs/site.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- site.xml 29 Feb 2004 19:03:39 - 1.10 +++ site.xml 8 Mar 2004 14:09:28 - 1.11 @@ -42,10 +42,7 @@ --> - - - http://marc.theaimsgroup.com/?l=alexandria-dev&r=1&w=2"; label="Search List"/> - http://nagoya.apache.org/eyebrowse/SummarizeList?listId=198"; label="Browse List"/> + http://wiki.apache.org/gump"; label="Wiki"/> http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10457"; label="Issues"/> 1.1 gump/src/documentation/content/xdocs/mail.xml Index: mail.xml === Gump Mailing Lists Mailing Lists Please read the http://jakarta.apache.org/site/mail.html";>guidelines of the Jakarta Project before subscribing and posting to the Gump general list as they apply to this list as well. Like almost all lists of the Apache Software Foundation, Gump's list is a subscriber only lists, this means you have to subscribe before you can post to the list. Please note that any HTML parts sent to the lists will be removed by our mailing list software - you shouldn't be sending HTML mails anyway. General List Medium Traffic mailto:[EMAIL PROTECTED]">Subscribe mailto:[EMAIL PROTECTED]">Unsubscribe http://mail-archives.apache.org/eyebrowse/SummarizeList?listId=227";>Archive http://marc.theaimsgroup.com/?l=gump&r=1&w=2";>alternative Archive This is the list where participating developers, users and metadata maintainers of Gump meet and discuss issues, code and metadata changes/additions, etc. Subscribers to this list get notices of each and every code/metadata change, build results, testing notices, etc. 1.8 +1 -1 gump/src/documentation/content/xdocs/python/usage.xml Index: usage.xml === RCS file: /home/cvs/gump/src/documentation/content/xdocs/python/usage.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- usage.xml 29 Feb 2004 19:03:39 - 1.7 +++ usage.xml 8 Mar 2004 14:09:29 - 1.8 @@ -60,7 +60,7 @@ python gump\gui\view.py -w ..\myworkspace.xml -cd /jakarta-gump/python +cd /gump/python export PYTHONPATH=`pwd` python gump/gui/view.py -w ../myworspace.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Moving gump forward
Stefano Mazzocchi wrote: RT is where you throw you thought in the mix and see what happens. It could be the best thing or the most silly idea. this is a good one. Summary of some important thoughts so far. Gump social maintenance costs are still too high on the gumpmaisters and not well distributed horizontally across the various projects. indeed. Gump as a social experiment takes its toll on the experimentors. As I said previously, gump is just too verbose. Beside gump own developers, Gump is the kind of web site that you look at only when there are problems. you know, I'm inclined to design a 'mock' workflow package here, conduct tests of people's behaviour, improve the mock, etc. The gump workflow is *complex*. Not that I actually know much about user interface testing ;) at this point I'll let the discussion start on what should be on that page. we need guinea pigs :-D = Workflow = let's try to describe the optimal gump workflow. I've found (in describing this to other people), that the current gump workflow is much like working on (someone else's) spagetti code. It seems we need the equivalent of "code insight" features. How would that work? Send me an e-mail saying my project failed to build. Include a link that will take me to the (highlighted) part of the build output that seems to be the problem. Make references to classnames 'n stuff clickable. Clicking on a classname (ie as spit out by the compiler when there's a problem) takes me to the build log of the dependency. If another project failed because of my change, send me an e-mail pointing to that failure (those failures). Indicate the classes that seem to be the problem. Tell me when the project started failing and provide me a ViewCVS link that indicates the class that is apparently causing problems for the other project. As a first step, let people look at the cvs history themselves. Automation seems nice, but there's also a lot that can be done just by making the UI as powerful as possible. But since we're going by leaps and bounds right now...we need a wiki-style workflow. Ditch CVS and provide me with an "edit this descriptor" page. The task of finding the right descriptor to edit can be several minutes of work. That should change to several seconds. = The Human Factor = What I really like about gump is the principle that we emulate developer behaviour as much as possible. We could just let the metadata point to the sources, do away with ant alltogether, and implement an IDE-like compiler. But then gump would be able to build lots of things that might fail to build on the commandline. = The friggin' broken buildsystem = It's not always a classfile change that broke things. In the avalon case, for example, the projects that are failing to build haven't seen very significant API change. The build itself is broken. Maybe we should fall back to trying a non-ant build when that happens. Is it possible to detect an ant (or maven) failure as opposed to an api change? Is it worthwhile to seperate it out. = Let's go relational = We want to build a complex, flexible, relational model of all these builds. Maybe its just me, but XML doesn't express that too well. It's much easier to express some fomrs of "intelligence" in SQL. Enough brainstorming for tonight. I have more to say, but gotta run right now :-D -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ --- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: feature request: top critical failures
On Sun, 07 Mar 2004, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > With "nobody gives a damn" I meant none of the avalon people. They are possibly busy bashing each other. Oops, off topic. > There are two paths here: > > 1) make gump smart enough to work with that's out there The problem with most of the excalibur components is that their build files simply don't work. Neither using Gump nor running Ant from the command line. I'm not sure whether they'd actually build using Maven, I've come to have my doubts here as well. But this probably is the only option for Gump, run Maven for projects that build using Maven since the developers will never run the build files they provide and thus never know that those build files don't work. >> I will give a shout to the xdoclet guys concerning this later. Antoine, consider pinging Erik Hatcher, he has commit access to the xdoclet module. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Moving gump forward
In message <[EMAIL PROTECTED]>, "Daniel F. Savarese " writes: >Another heuristic approach that would work for Java projects at >least, would be to analyze the build failure messages. Usually >they'll reference a class or class member/method that is in >a dependent code base. Develop an evolving library of patterns >to extract the offending methods/classes/etc. and then discover >what jar they came from. Right after I sent that I realized that there's a more effective variation of this idea. The compiler often knows exactly why a compile failed. It should be possible to extend one of the several Java compilers out there with some Gump-aware code that will map the package an offending programming construct belongs to back to the project it belongs to. That doesn't help you directly in the case when an API artifact is removed or renamed (although it does help when a method signature changes), but it does help you narrow down the change based on the packages imported by the file. So you can limit the scope of dependencies on which you apply the brute force comparative build approach. In fact, for Java code, instead of going to the trouble of enhancing the compiler, it may be enough just to look at the packages in the file(s) that failed to compile based on the error message spewed by the compiler. Maybe it's better to think about how a human goes through the process of tracking down the source of a failure and see how that can be emulated. Again, that's assuming that 100% accurate solutions are too computationally expensive to be practical. That's it for my RT contribution. I'm on EST. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: feature request: top critical failures
On Sat, 6 Mar 2004, Adam R. B. Jack <[EMAIL PROTECTED]> wrote: >> I will try to suggest a new build.xml to the avalon team for this >> component. May be it could be built with Maven, but I do not know >> Maven, and I do not know either the interface between gump and >> Maven. > > The way is it (was) meant to work is on types "maven ant" (I think > this is the goal, to get a build.xml) and "maven gump" to get a Gump > descriptor. I think that this is not what the Avlon team has done, it looks more as if they had tried to manually create Ant build files to simulate Maven. "maven ant" and "maven gump" have some quirks as well, at least with some versions of Maven - Ant build files sometime contain absolute paths that are only correct for the machine that has done "maven ant". > I beleive Stefan knows of a reason why some need to get things to work, but that can be step two. He has some vague theories ;-) > BTW: We do now have Gump (at least Gumpy) building via Maven, and > I'd like to see it tried on something real. This occurs when is used instead of and one using so we can compare the results. > I'd be tempted to have Gump write the build script on the fly, from > the information in the metadata, This would never work 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Moving gump forward
In message <[EMAIL PROTECTED]>, Stefano Mazzocchi writes: >Now, I think it's possible (even if computationally expensive) to >understand exactly what commit broke the build and to nag the exact >person and the community and copy all the offended people. ... >for those not familiar with exponential growth, it's enough to say that >if the build took a minute it would take gump 2,5 billion years to find >out what broke the build. Why don't you start with the easy stuff. If a build of project A fails, we know all builds depending on project A will fail. But if project A is dependent on project B, and project B failed, then we keep on walking up the tree to find the first build that failed. Okay, so now that leaves the issue of a build failing because of an API or some other change in a dependent project that built successfully. For projects with a small number of dependencies, use the brute force approach you described. For projects with a large number dependencies, develop some heuristics. You can reason that if project B makes a change that breaks project A and if C also depends on project B, then there's a chance project C might also have broken. Since Gump builds a ton of code bases, a decent number of culprits (i.e., project B) could be identified by analyzing the dependencies shared by projects that failed to build. You can then apply the brute force approach to only those shared dependencies if they number below some manageable figure. Another heuristic approach that would work for Java projects at least, would be to analyze the build failure messages. Usually they'll reference a class or class member/method that is in a dependent code base. Develop an evolving library of patterns to extract the offending methods/classes/etc. and then discover what jar they came from. Anyway, those are some inelegant, inxact, and simplistic--but perhaps useful in some instances--suggestions about how to start adding the functionality you describe that would buy time to figure out how to do it right. That is, assuming it's a hard problem that requires a good while to figure out. My reasoning is that it's okay to nag the wrong projects every once in a while as long as you nag the right projects most of the time. And on first glance, based on your comments, it seems easier to implement that than to figure out the right project to nag all the time. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
