Bylaws
Hi, one of the few remaining tasks (the only one AFAICS) to have as established as a TLP is the definition of bylaws. I've put my thoughts on bylaws on a wiki page[1], please comment there as well. Cheers Stefan Footnotes: [1] http://wiki.apache.org/gump/Drafts/ProjectBylaws - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] Updated: LocalSpellingWords
Date: 2004-03-12T04:23:40 Editor: StefanBodewig [EMAIL PROTECTED] Wiki: Gump Wiki Page: LocalSpellingWords URL: http://wiki.apache.org/gump/LocalSpellingWords no comment Change Log: -- @@ -88,3 +88,5 @@ abbrechen Ablaufzeit anklickt Bearbeiter Browserfenster durchbekommen editierbar Editierens Editiersitzung Editiersperren Editiervorgang Editiervorgangs gleichzeitiges hinweist Schlusszeit Sperreigenschaft Sperrens Sperrsystems Warnhinweis Wikiseite Zeitnahme Zeitnehmer Zwischensicherung Sperrmechanismus + +Apache Avalon committer committers Gump Maven metadata - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] New: Drafts/BoardReports/20040317
Date: 2004-03-12T04:23:50 Editor: StefanBodewig [EMAIL PROTECTED] Wiki: Gump Wiki Page: Drafts/BoardReports/20040317 URL: http://wiki.apache.org/gump/Drafts/BoardReports/20040317 no comment New Page: Most of the past few weeks has been filled with infrastructure stuff. We've successfully migrated web-site, CVS module, bug-tracking and the mailing list to gump.apache.org - many thanks to the infrastructure team for making the transition that smooth. All Apache committers have been Gump committers with the old setup and this still remains true. We want to get as many people involved as possible when it gets to maintaining the project metadata. This is the reason that we've been sticking to CVS for now since we can reach most Apache committers that way. Gump will probably be one of the last projects that make the transition to Subversion. Work on the project bylaws has started and we expect to have them ready for the next board meeting. Gump is unique when it comes to committer status so we'll have to put some thoughts into the definition of that role. Gump has been quite successful in pointing out problems in some builds recently and we are happy that most of them have been resolved between projects easily. Our biggest problem right now is building Avalon, but this may be due to the fact that Gump is using a different build system than Avalon more than anything else. Once Gump supports Maven as a build option, things may become easier for Avalon. We continue improving the Python rewrite of Gump and have come quite a long way already. Since nobody of us is anywhere near a Python guru, we may be doing things far more complicated than necessary. Any help is welcome. 8-) The future steps for Gump are * get dedicated ASF hardware to run Gump on - we are really looking forward to the new machine. * expand Gump's reach beyond building Java projects. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Board report
Hi, all PMCs, well, the chairmen, have to report to the board quarterly and we've ended up for March, June, September and December in the rotation. In addition we need to report in April so that the board knows we are on track. I'd like to try authoring the board report together and have started with my thoughts for next week's meeting in the wiki[1]. Please go ahead and modify/add to your liking. Stefan Footnotes: [1] http://wiki.apache.org/gump/Drafts/BoardReports/20040317 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/python/gump engine.py build.py
ajack 2004/03/12 06:21:00
Modified:python/gump engine.py build.py
Log:
Allow build to run standalone w/o loading stats
Revision ChangesPath
1.82 +41 -11gump/python/gump/engine.py
Index: engine.py
===
RCS file: /home/cvs/gump/python/gump/engine.py,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -r1.81 -r1.82
--- engine.py 11 Mar 2004 16:13:50 - 1.81
+++ engine.py 12 Mar 2004 14:21:00 - 1.82
@@ -391,6 +391,33 @@
**
+def build(self,run,all=1):
+
+#
+# Load the statistics (so we can use them during
+# other operations).
+#
+#logResourceUtilization('Before load statistics')
+#self.loadStatistics(run)
+
+#
+# Run the build commands
+#
+logResourceUtilization('Before build')
+if all:
+self.buildAll(run)
+else:
+self.buildProjects(run)
+
+# Return an exit code based off success
+# :TODO: Move onto run
+if run.getWorkspace().isSuccess():
+result = SUCCESS
+else:
+result = FAILED
+
+return result
+
def buildAll(self,run):
Build a GumpRun's Full Project Stack
@@ -426,28 +453,31 @@
# Extract stats (in case we want to do conditional processing)
-stats=project.getStats()
+stats=None
+if project.hasStats():
+stats=project.getStats()
if project.isPackaged():
-self.performPackageProcessing( run, project, stats)
+self.performPackageProcessing(run, project, stats)
continue
# Do this even if not ok
-self.performPreBuild( run, project, stats )
+self.performPreBuild(run, project, stats)
wasBuilt=0
if project.okToPerformWork():
log.debug(' -- Building: [' + `projectNo` + '] ' +
project.getName())
# Turn on --verbose or --debug if failing ...
-if (not STATE_SUCCESS == stats.currentState) and \
-not project.isVerboseOrDebug():
-if stats.sequenceInState 5:
-project.addInfo('Enable debug output, due to error.')
-project.setDebug(1)
-else:
-project.addInfo('Enable verbose output, due to error.')
-project.setVerbose(1)
+if stats:
+if (not STATE_SUCCESS == stats.currentState) and \
+not project.isVerboseOrDebug():
+if stats.sequenceInState 5:
+project.addInfo('Enable debug output, due to error.')
+project.setDebug(1)
+else:
+project.addInfo('Enable verbose output, due to
error.')
+project.setVerbose(1)
#
# Get the appropriate build command...
1.42 +2 -5 gump/python/gump/build.py
Index: build.py
===
RCS file: /home/cvs/gump/python/gump/build.py,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- build.py 8 Mar 2004 22:28:08 - 1.41
+++ build.py 12 Mar 2004 14:21:00 - 1.42
@@ -65,11 +65,8 @@
#
#Perform this integration run...
#
-if '*' in args:
-result = engine.buildAll(run)
-else:
-result = engine.buildProjects(run)
-
+result = engine.build(run, '*' in args)
+
#
log.info('Gump Build complete. Exit code:' + str(result))
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Cactus] commons-codec added to dependency jars?
Vincent Massol wrote: -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 11 March 2004 10:31 To: [EMAIL PROTECTED] Subject: Re: [Cactus] commons-codec added to dependency jars? On Thu, 11 Mar 2004, Vincent Massol [EMAIL PROTECTED] wrote: Cactus does not use directly commons-code. It may be used by a cactus dependency like Tomcat, Commons HttpClient or others. I think it is httpclient. Wouldn't it be better to add this dependency to the project directly using it and then use an inherit=runtime or something similar for Cactus? +1 Again the problem is the same. I don't have access to a gump machine and I don't want to make a CVS change if I can verify it still works... I think if you want to make Gump more popular (in the line of thought of the [RT] thread), this is one area to improve. A self-service Gump or something similar so that people can help modify descriptors and verify they still work. Otherwise the Gump committers will end up doing all the work... Vincent, I'm actually very curious and insterested in your comment: what are you afraid of breaking? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Gumpy deploying websites?
Vincent Massol wrote: Hi, In the past, Sam had provided some configuration so that Gump would upload every day the Cactus website (built as part of the Cactus build) to jakarta.apache.org/cactus. That was quite nice. I'd love to see Gump(y) add even more value to projects (such as deploying their web sites every night - for Apache projects who configure this in their deployment descriptors). Note: I think related security issues can be solved without too much problem (for example by allowing only to deploy to cvs.apache.org). Thoughts? -1 this is a asking for trouble. Gump is the most insecure system ever, since it downloads software from all over the world. This means that even a committer of a library that we depend upon could gain control of gump and use its ssh keys to upload nasty content on your web site. In a security chain, the weakest ring is the problem, not the strongest, and gump has soo many of these weak rings that it is actually impressive that nothing has happened so far. There are talks with infrastructure guys about setting up the new gump machine so that it is *wiped out* every night and reinstalled completely from scratch, operating system included. Rather drastic, I agree, but if we want gump to be trusted by the HTTPD folks we must start thinking about security way more seriously and not trust any artifact that gump produces. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Clarifying some licensing issues for Apache developers
From: Stefano Mazzocchi [EMAIL PROTECTED] [...] Food for thought. Slick ideas, I love them... regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[head-up + vote] Gump should identify itself!!
Geir Magnusson Jr wrote: It's not me :) It's gump. People, I propose that Gump should identify itself as Apache Gump rather than with the name of the person that onw the project. Vote? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: How to debug a Gump build problem?
Uh, Adam and Antoine asked access to moof and I gave it to them. I didn't do anything else. Guys, status? I'd point you to a posting (yesterday) with a subject of 'gump on moof', but our eyebrowse index seems dorked. Can you see it? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Moving gump forward
Scott Sanders wrote: On Mar 9, 2004, at 2:27 AM, Stefan Bodewig wrote: BTW: I suspect that gump could implemented by writting the ant script on the fly w/o us having to reinvent the wheel. See the antgump proposal in Alexandria - maybe Scott can chime in here? My latest try was vindico, an ant-based gump. I got far enough to see things building and so on, but not far enough to do the project.xml override/inheritance. I do believe it was a viable model, the biggest issue being that I was still using java products to build java products, and Sam had warned me about these types of things. I only stopped because Adam had started pushing more and more code into Gumpy, and I liked the idea of using non-Java to build Java. That, and he was coding much more than I was :) In short, there are a couple of gotchas with an ant-based gump, but I think it is completly doable. My other ambitions with vindico were more what we are talking about today: doing history on all builds, trying to find who to blame (usually 1 side of a 2-sided interface), moving more toward some type of continuous integration, federation of gumps (so that I am only building 4 projects), etc. I think that gump should *NOT* try to reinvent the wheel and simply make sense of what the projects already do. Keep in mind that gump is currently a top level project and we aim at building *EVERYTHING* the ASF does, including HTTPD. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [head-up + vote] Gump should identify itself!!
On Fri, 12 Mar 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote: People, I propose that Gump should identify itself as Apache Gump rather than with the name of the person that onw the project. Fine with me, but Gump needs to use an address that is subscribed to the -dev list (or a benevolent moderator). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump on moof
Copying Fred since he's the administrator of that machine and the osx man [FYI, he's the one who wrote parts of the Darwin kernel for OSX] Adam R. B. Jack wrote: It jumped onto moof and ran gump/check.py, and it (at least) runs our of the box (ok, out of CVS), which is a beautiful thing. nice to hear. Now, after a little planning, it is time to install Gumpy proper... A set of location questions (and as you know, I know nada about OSX, so feel free to completely alter all suggestions): 1) Where ought we put the code (checked out from cvs:gump)? /Gump/gump? put it on /usr/local/gump/gump [which mounts to /Volumes/data that has 33gb of free disk] 2) Where ought we put the packages? /Gump/Opt? /usr/local/gump/packages 3) Where ought we put the workspace /Gump/WS? [It will be *big*] /usr/local/gump/workspace 4) Where ought we put the HTML log output (so http://moof... can pick them up?] /usr/local/gump/results I will setup the apache conf files accordingly once you have something to show [this makes it easier to remap it to the URL space] I'd like the opportunity to run multiple Gump workspaces on this machine (perhaps some simple test ones, perhaps some 'docs centric ones', etc.) so I'd like to do some sort of /X/ on the end of each of these, where X is Public or ... in that case, I would suggest you keep /usr/local/gump as the base location and then do /usr/local/gump/[flavor]/gump /usr/local/gump/[flavor]/packages /usr/local/gump/[flavor]/workspace /usr/local/gump/[flavor]/results for each flavor. Please populate a README file on /usr/local/gump/README to describe the installation and how to replicate it in case somebody wants to do it or to understand what's in there. Thanks much for you work on this, it's very appreciated! ah, last thing, can you give us an estimation of the amount of disk space that you need? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Gumpy deploying websites?
Stefano Mazzocchi wrote: Gump is the most insecure system ever, hpfft. since it downloads software from all over the world. This means that even a committer of a library that we depend upon could gain control of gump and use its ssh keys to upload nasty content on your web site. Gump security is based on its profile, environment, and permissions, just like for any other process. You could probably set up a restricted gump instance with a restricted profile, restricted access, etc etc. Run it on an infrastructure-controlled box. Run a restricted profile. Use http redirects, read only NFS mounts, or a pull based setup. In other words: replace part of forrestbot with gump. From a security perspective, gump is a python script controlled using XML configuration that knows how to download things from cvs and svn, how to run ant and other tools on those downloaded things, and what to do with the results of those tool invocations. This is not inherently less secure than, say, putting a crontab file in CVS. -- 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: cvs commit: gump/blog/Issues Struts-Velocity.txt
Martin Cooper wrote: On Thu, 11 Mar 2004, Nick Chalko wrote: Is it premature to talk about this? http://gump.chalko.com/gb/blog/Issues/?smm=ypermalink=Struts-Velocity.txtpreview=true I like to keep the visibility up. but is the risk of stepping on toes to large? In principle, I don't mind this, but a couple of points to bear in mind: 1) The breakage happened 3 weeks and 6 days ago, but it was not until today that a message was sent to struts-dev informing us of the problem. We can't track all of the client projects, so if we break something, someone needs to let us know. It would be nice if that happened rather less than a month after the problem, because who knows what else might have happened in the code base since that change, making it that much harder to resolve. If the offending project is notified, and the problem persists for some period of time after that (more than a couple of days, but less than a month), *then* it is reasonable to go blog about it publicly. But please don't go posting about problems that the team either hasn't been notified of yet, or has only just heard about. 2) The wording in the blog entry is not exactly friendly, specifically the show them what they are doing is harmful to client projects. This sounds like a parent scolding a naughty child. Yes, we know it's not good, but we didn't sit around and try to come up with ways to break Velocity-Tools. It was an accident, and we'll fix it. You are right, the tone of the message is not helpful at all. We must make a serious effort to show that gump is fostering communication, not blaming and pointing fingers!! Also, let's leave the people a break and report things when they are solved not then they appear!!! -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Dodgy characters forrest (xdocs)
I think I've managed to suppress dodgy characters (like the binary that log4j's test cat'ing .gz files produced). It isn't pretty/nice, I replace them with _, but at least the forrest ought run for all the other pages. http://gump.try.sybase.com/logging-log4j/log4j-tests.html BTW: I thought I could use Python codecs with the 'ignore' or 'replace' or 'replace w/ xml' options, but they seemed to barf on bad input characters (probably 'cos they assumed a valid ASCII input, or something.) So, I had to do a replace. BTW: I edited out the crap ran the LSD full run's forrest by hand earlier. regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump on moof
Stefano Mazzocchi wrote: ah, last thing, can you give us an estimation of the amount of disk space that you need? [EMAIL PROTECTED] /data3]$ df -h FilesystemSize Used Avail Use% Mounted on (...) /dev/hdb2 27G 7.7G 18G 31% /data3 so that's approx. 8 GB per full instance/flavor at the moment, and some more during the runs. Expect this to grow as gump grows (and the success percentage increases); a minimum 15GB to start with I think for the initial setup. -- 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]
Problem with build of jakarta-slide
Hi Adam, can you check whether gumpy *syncs* properly on lsd. Stefan http://article.gmane.org/gmane.comp.jakarta.ant.devel/28636 wrote that Slide should build. I have seen that jakarta-slide/build.xml and jakarta-slide/testsuite/build.xml have been synced from CVS last night. Can you check whether the files have been copied afterwards from /data3/gump/cvs/jakarta-slide to /data3/gump/jakarta-slide ? Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] Updated: Drafts/ProjectBylaws
Date: 2004-03-12T07:22:17 Editor: 65.96.189.168 Wiki: Gump Wiki Page: Drafts/ProjectBylaws URL: http://wiki.apache.org/gump/Drafts/ProjectBylaws no comment Change Log: -- @@ -34,8 +34,12 @@ ''I'll suggest that a PMC vote is a good idea, and that either is actually a good plan. People can ask and then the PMC can vote. Or the PMC can ask and vote and people can then accept.'' -- LSD +''I'm obviously biased but I think that 'just ask' is the way to go. I mean, the gump PMC is mostly going to be dead since we don't really redistribute gump outside anyway. What's the point of having to vote if the vote is always going to be positive because there would be no reason to be negative?'' -- SM + * where do votes happen. This is not formally defined in most bylaws. The real question is where to vote on people. Jakarta based projects have the tradition to even perform this type of votes in public, while the very idea of public votes on people is alien to most people from a http background. Since we want to invite participation from the whole of the ASF I'd suggest to restrict votes on people, as far as we actually need any, to the PMC list. ''agreed.'' -- LSD + +''in case of voting is required, I'm fine with either'' -- SM == Actual Draft == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with build of jakarta-slide
Adam R. B. Jack wrote: can you check whether gumpy *syncs* properly on lsd. You don't have unfailing confidence in your code? ;-) No, unfortunately, I do not have unfailing confidence in my code. :-( Actually, I might have busted it w/ that skip directories like .svn|CVS that I added yesterday. Don't know. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump on moof
put it on /usr/local/gump/gump Thanks. Somebody mind creating a /use/local/gump directory that the gump group has permissions to? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Account for Antoine
FYI: I set up an account for Antoine on lsd. Another person to blame if things break :-D. Whoohooh! -- 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: Gump on moof
I would like also to be in this group. Cheers, Antoine Stefan Bodewig wrote: On Fri, 12 Mar 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: Somebody mind creating a /use/local/gump directory that the gump group has permissions to? And please add me to that group while you are at it. Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/python/gump engine.py
ajack 2004/03/12 08:10:39
Modified:python/gump/document forrest.py xdoc.py
python/gump/model stats.py
template/forrest/src/documentation/content/xdocs site.xml
python/gump engine.py
Log:
1) Allow 'TAB' not to be mapped to underscore
2) Create _fixes pages showing recent changes to success (with description)
3) Added description paragraph to _todos (the opposite of 2).
Revision ChangesPath
1.102 +141 -8gump/python/gump/document/forrest.py
Index: forrest.py
===
RCS file: /home/cvs/gump/python/gump/document/forrest.py,v
retrieving revision 1.101
retrieving revision 1.102
diff -u -r1.101 -r1.102
--- forrest.py12 Mar 2004 14:47:48 - 1.101
+++ forrest.py12 Mar 2004 16:10:39 - 1.102
@@ -500,6 +500,9 @@
totalAffected=0
projectsSection=document.createSection('Projects with issues...')
+projectsSection.createParagraph(These are the project that need 'fixing'.
+This page helps Gumpmeisters (and others) locate the main areas to focus attention.
+The count of affected indicates relative importance of fixing this project.)
projectsTable=projectsSection.createTable(['Name','Affected',\
'Dependees', \
'Duration\nin state','Project State'])
@@ -543,6 +546,66 @@
'Total Affected Projects: ' + str(totalAffected))
document.serialize()
+
+#
+# --
+#
+# project_fixes.xml -- Projects w/ fixes in build order
+#
+document=XDocDocument('Project Fixes', \
+self.resolver.getFile(workspace,'project_fixes'))
+self.documentSummary(document, workspace.getProjectSummary())
+
+totalAffected=0
+
+projectsSection=document.createSection('Projects with fixes...')
+projectsSection.createParagraph(These are the projects that were 'fixed'
(state changed to success) within %s runs.
+This page helps Gumpmeisters (and others) observe community progress.
+ % INSIGNIFICANT_DURATION)
+
+projectsTable=projectsSection.createTable(['Name','Affected',\
+'Dependees', \
+'Duration\nin state','Project State'])
+pcount=0
+for project in sortedProjectList:
+if not gumpSet.inProjectSequence(project): continue
+
+if not project.getState()==STATE_SUCCESS or \
+not project.getStats().sequenceInState INSIGNIFICANT_DURATION:
+continue
+
+pcount+=1
+
+#
+# Determine the number of projects this module (or it's projects)
+# cause not to be run.
+#
+affected=project.determineAffected()
+totalAffected += affected
+
+# How long been like this
+seq=stats=project.getStats().sequenceInState
+
+projectRow=projectsTable.createRow()
+projectRow.createComment(project.getName())
+
+self.insertLink(project,workspace,projectRow.createData())
+
+projectRow.createData(affected)
+
+projectRow.createData( project.getFullDependeeCount())
+
+projectRow.createData(seq)
+
+self.insertStateIcon(project,workspace,projectRow.createData())
+
+if not pcount:
+projectsTable.createLine('None')
+else:
+projectsSection.createParagraph(
+'Total Affected Projects: ' + str(totalAffected))
+
+document.serialize()
#
# --
@@ -553,7 +616,10 @@
self.resolver.getFile(workspace,'module_todos'),)
self.documentSummary(document, workspace.getProjectSummary())
-modulesSection=document.createSection('Modules with TODOs')
+modulesSection=document.createSection('Modules with TODOs')
+modulesSection.createParagraph(These are the modules that need 'fixing',
or contained projects that need fixing.
+This page helps Gumpmeisters (and others) locate the main areas to focus attention.
+The count of affected indicates relative importance of fixing this module.)
RE: [Cactus] commons-codec added to dependency jars?
Hi Stefano, -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: 12 March 2004 15:31 To: Gump code and data Subject: Re: [Cactus] commons-codec added to dependency jars? [snip] Again the problem is the same. I don't have access to a gump machine and I don't want to make a CVS change if I can verify it still works... I think if you want to make Gump more popular (in the line of thought of the [RT] thread), this is one area to improve. A self-service Gump or something similar so that people can help modify descriptors and verify they still work. Otherwise the Gump committers will end up doing all the work... Vincent, I'm actually very curious and insterested in your comment: what are you afraid of breaking? The way I code is as follows: 1/ make a change on my local machine 2/ verify it works by running some kind of tests If I don't do 2/ then there is a high chance it will break something and I'll only know the following day. To do 2, there are 2 solutions I can see: 1/ install gumpy locally but that's not very easy to do 2/ have a kind of self-service gumpy that you can start on demand What do you think? Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/blog/Issues Struts-Velocity.txt
Stefano Mazzocchi wrote: Nick Chalko wrote: Is it premature to talk about this? http://gump.chalko.com/gb/blog/Issues/?smm=ypermalink=Struts-Velocity.txtpreview=true I like to keep the visibility up. but is the risk of stepping on toes to large? Reading it again I see that the people side of it came out harsh. I will make sure to use softer words in the future. I think that it's fine if you remove the compiler error and keep it focused on the social aspect of things. [that is Stuts and Velocity have to work together to solve the issue] I thought the compile error would be good for google and others facing the same issues. Given that I stepped on toes it is very important that we remeber to blog about the success. R, Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying to get Gumpy running ...
You know, irregardless of how mature (or otherwise) Gumpy is in integrate.py, the other scripts -- and the general commandline usage -- are terribly immature. Basically, with me not having the ability to do any worthwhile local runs (behind a modem) I've really just never bothered. [Ok, I've also been fighting too many maintenance issues, like dodgy characters, to get to it.] Gump has all the pieces to do all the things it should (and that Traditional supported) they just aren't wired that way yet. [They are so close, and I took another quick whack last week, just not completely there.]: 1) We have GumpRun with lists of (1) 'the specified projects' [if not in build order], (2) 'the full build sequence for those projects', (3) the modules containing those projects (4) the sequence or modules. 2) We have GumpRunOptions with switches to control paths we take. 3) We have command line processing that (now) returns a GumpRunOptions object. --verbose|--debug --quick (a hack to say 'do list not sequence','use cached') Basically, we need to flesh out the commandline options and what each should do. I think we need a --cache to allow cached descriptors. I think we need a --text (to ignore forrest, even if it is available), and so on. We probably ought create a wiki page for command line options. Anybody interested in taking this on? It'd be a big help. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with build of jakarta-slide
Hmm, maybe the issue was that the dodgy characters in log4j-test were killing the forrest, so the pages were stale. I hand ran the forrest about the time you sent this, and right now it shows success (with a duration of 1). http://lsd.student.utwente.nl/gump/jakarta-slide/jakarta-slide.html Still, what you are asking is interesting, it is interesting to see the things that a build does, that vary from CVS|SVN. I wonder if we ought allways do such a diff -r, for curiosity reasons: Can you check whether the files have been copied afterwards from /data3/gump/cvs/jakarta-slide to /data3/gump/jakarta-slide [EMAIL PROTECTED] ajack]$ diff -r /data3/gump/cvs/jakarta-slide /data3/gump/jakarta-slide Only in /data3/gump/jakarta-slide: build Only in /data3/gump/jakarta-slide: dist diff -r /data3/gump/cvs/jakarta-slide/testsuite/CVS/Entries /data3/gump/jakarta-slide/testsuite/CVS/Entries 9c9 /build.xml/1.25/Fri Mar 12 01:18:55 2004// --- /build.xml/1.23/Thu Mar 11 01:21:12 2004// Only in /data3/gump/jakarta-slide/testsuite: dist Only in /data3/gump/jakarta-slide/testsuite/lib: commons-httpclient.jar Only in /data3/gump/jakarta-slide/testsuite/lib: jakarta-slide-webdavlib-20040312.jar Only in /data3/gump/jakarta-slide/testsuite/lib: jdom.jar Only in /data3/gump/jakarta-slide/testsuite/lib: tprocessor.jar Only in /data3/gump/jakarta-slide/testsuite/testsuite/junit: debug Only in /data3/gump/jakarta-slide/webdavclient: build Only in /data3/gump/jakarta-slide/webdavclient: dist [EMAIL PROTECTED] ajack]$ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [head-up + vote] Gump should identify itself!!
Stefan Bodewig wrote: People, I propose that Gump should identify itself as Apache Gump rather than with the name of the person that onw the project. Fine with me, but Gump needs to use an address that is subscribed to the -dev list (or a benevolent moderator). We can use the pattern Gump @ Host [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gumpy deploying websites?
Leo Simons wrote: Stefano Mazzocchi wrote: Gump is the most insecure system ever, hpfft. since it downloads software from all over the world. This means that even a committer of a library that we depend upon could gain control of gump and use its ssh keys to upload nasty content on your web site. Gump security is based on its profile, environment, and permissions, just like for any other process. You could probably set up a restricted gump instance with a restricted profile, restricted access, etc etc. Run it on an infrastructure-controlled box. Run a restricted profile. Use http redirects, read only NFS mounts, or a pull based setup. In other words: replace part of forrestbot with gump. From a security perspective, gump is a python script controlled using XML configuration that knows how to download things from cvs and svn, how to run ant and other tools on those downloaded things, and what to do with the results of those tool invocations. This is not inherently less secure than, say, putting a crontab file in CVS. there is a huge difference, Leo. forrestbot is never executing anything, gump is and is executing things that are downloaded from an external untrusted environment. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Depot svn is failing on covalent.
http://gump.covalent.net/log/cvs_depot.html Any Ideas? R, Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monthly clean of cvs dir.
I think we should to a month clean of the cvs dirs. a rm -rf . This will help us catch errors that outdated cvs dir would otherwise miss. The only negative I foresee with this, is that currently Gumpy uses the output of the CVS|SVN updates (in quiet mode) to determine if there have been any updates. A monthly clean would (as implemented today) throw this off: http://lsd.student.utwente.nl/gump/gump_stats/module_updated.html Now, since we are on the topic -- is there a better way to ascertain what updates occurred? I suspect we could check file dates/time stamps, but are there CVS|SVN ways? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monthly clean of cvs dir.
Adam R. B. Jack wrote: I think we should to a month clean of the cvs dirs. a rm -rf . This will help us catch errors that outdated cvs dir would otherwise miss. The only negative I foresee with this, is that currently Gumpy uses the output of the CVS|SVN updates (in quiet mode) to determine if there have been any updates. A monthly clean would (as implemented today) throw this off: http://lsd.student.utwente.nl/gump/gump_stats/module_updated.html Now, since we are on the topic -- is there a better way to ascertain what updates occurred? I suspect we could check file dates/time stamps, but are there CVS|SVN ways? use cvs -n up to test for updates, then do delete the dirs and do a update. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project incubator-geronimo.xml
ajack 2004/03/12 15:10:22 Modified:project incubator-geronimo.xml Log: Remove maven depend, to see if installed maven will work... Revision ChangesPath 1.3 +3 -1 gump/project/incubator-geronimo.xml Index: incubator-geronimo.xml === RCS file: /home/cvs/gump/project/incubator-geronimo.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- incubator-geronimo.xml27 Feb 2004 09:22:56 - 1.2 +++ incubator-geronimo.xml12 Mar 2004 23:10:22 - 1.3 @@ -26,7 +26,9 @@ project name=incubator-geronimo maven goal=default /maven -depend project=maven inherit=runtime/ +!-- Since Maven is installed, not built, this + isn't strictly neccessary. [yet] + depend project=maven inherit=runtime/ -- packageorg.apache.geronimo/package depend project=junit/ depend project=mx4j/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Gump Wiki] New: GumpCommandLineOptions
Date: 2004-03-12T15:14:52
Editor: AdamJack [EMAIL PROTECTED]
Wiki: Gump Wiki
Page: GumpCommandLineOptions
URL: http://wiki.apache.org/gump/GumpCommandLineOptions
no comment
New Page:
GumpCommandLineOptions.
All Gump scripts (currently) have the same commandline:
python gump/x.py [options] -w {workspace} {project expression}
Available:
* -w {workspace file} --- reference to workspace file.
* {project expresion} --- e.g. 'all'
Options:
* -d|--debug -- turn on Gump debugging
* -v|--verbose -- not much different than above right now.
Proposed:
* --optimized -- only compile things if updated
* --cached -- allow cached descriptors (don't download over HTTP, and certainly don't
CVS update)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (GUMP-21) FOG factor is misleading and requires improvement
The following comment has been added to this issue: Author: Adam Jack Created: Fri, 12 Mar 2004 3:43 PM Body: I'd love to fix this, I agree with much of the objection, but I'd need suggestions. I suspect there is no such thing as a single 'FOG Factor' (to suit all purposes) but maybe it is a quick eyeball. I think we need to factor in 'depth' (how much re-use a project leverages and cut it some slack for the good intentions.) Note: FOG Factor ought factor in failures due to an unstable stack, so we shouldn't ignore pre-req failures, maybe just weight them. Hmm, maybe we (somehow) factor in the 'depth' (max tree of dependencies) of the 'cause' that took it down. Any ideas welcomed... - View this comment: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-21page=comments#action_21006 - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-21 Here is an overview of the issue: - Key: GUMP-21 Summary: FOG factor is misleading and requires improvement Type: Improvement Status: Unassigned Priority: Major Project: Gump Components: Python Assignee: Reporter: Daniel Savarese Created: Thu, 4 Mar 2004 5:21 PM Updated: Fri, 12 Mar 2004 3:43 PM Description: FOG is defined right now as: def getFOGFactor(self): return round((float(self.successes) / (float(self.failures) + float(self.prereqs))), 2) This is not helpful. Last month, jakart-oro failed to build by coincidence around the time of a Gump run and the problem was fixed before the next Gump run, yet its FOG factor dropped in half. The responsiveness to resolving build and integration problems is not taken into account. It is likely that it is impossible for FOG to mean anything because the factors that determine a project's health (to borrow the term used by Adam Jack in an email to the commons-dev and gump lists) are largely orthogonal. FOG should probably be a vector and if you really wanted a single number you could use the length of that vector. One of the major problems with the current factor is that a project's FOG factor continues to increase when no changes have been made to the repository. It's not meaningful to count only successful builds towards improving the factor because no changes may have been made to the code base. Ideally, you count only builds that cause no failures after a change to the code base. FOG doesn't factor in how quickly (or slowly) projects recover from build failures, and how often changes to a code base cause failures (either in itself or in other projects). Right now, a project with few code changes (say once a month) that causes a failure 50% (1 every 2 months) of the time the code is changed with a mean time of failure correction of 1 week is deemed more reliable (higher FOG factor) than a project that makes frequent changes (say every day) to its code base and causes a failure 10% of the time (1 every 10 days) with a mean time of failure correction of 1 day. That's because FOG is based almost entirely on consecutive successful Gump builds, which is not useful. Rather than propose a new meaningless way of computing FOG, I suggest FOG stop being used temporarily. It would be more useful to break out and report all of the independently useful metrics and through experience over time determine how each impacts the overall notion of FOG and eventually derive a way of condensing the information (perhaps a FOG factor, perhaps a vector) in a useful manner. Right now the state of affairs is that someone decided FOG was a cool thing, so it's being reported and people see this number and mistakenly think a project with half the FOG factor of another is less dependable and therefore avoid using it. Alternatively an explanation of what FOG is intended to compute and how it is computed should be placed on Gump reports that list FOG so that consumers of the information will not be misled. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
