Hi, i posted a mail last week on [EMAIL PROTECTED], but got no response. Is anyone responsible for this mail list?
thanks roland -----Urspr�ngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 15. Oktober 2001 03:52 An: [EMAIL PROTECTED] Betreff: cvs commit: jakarta-alexandria/proposal/gump/site/xdocs index.xml status.xml rubys 01/10/14 18:52:24 Modified: proposal/gump/site/xdocs index.xml status.xml Log: FOP is clean again! Mention experimental runs... Revision Changes Path 1.3 +148 -138 jakarta-alexandria/proposal/gump/site/xdocs/index.xml Index: index.xml =================================================================== RCS file: /home/cvs/jakarta-alexandria/proposal/gump/site/xdocs/index.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- index.xml 2001/09/25 02:30:35 1.2 +++ index.xml 2001/10/15 01:52:24 1.3 @@ -1,138 +1,148 @@ -<?xml version="1.0"?> -<document> - - <properties> - <author email="[EMAIL PROTECTED]">Sam Ruby</author> - <title>Gump</title> - </properties> - -<body> - - <section name="What is Gump?"> - - <p> - Gump is a social experiment. The primary goal of Gump is to get diverse - projects to communicate early and often about integration, dependencies, - and versioning management. One way to think about it is that some of the - concepts of - <a href="http://www.extremeprogramming.org/";>Extreme programming</a> - applied to - <a href="http://www.martinfowler.com/articles/continuousIntegration.html";> - Continuous Integration</a> on an unprecedented scale. - </p> - - p> - Essentially, the reasoning goes like this - if continuous integration is a - good thing on a small project, why not apply it recursively and include all - dependencies for which access to source is provided? - </p> - - </section> - - <section name="How does Gump work?"> - <p> - <a href="http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/project "> - Project</a> definitions are converted from XML to scripts native to the - platform on which you are running. These scripts execute cvs update - commands for every module which contains a project being built, and - invoke builds for each project in an order that ensures that dependencies - are satisfied. - </p> - - <p> - The commands use the actual build.xml files from the projects, but do - not use the scripts or jar files checked into CVS. Instead, the - CLASSPATH is set and properties are passed on the command line. - </p> - - <p> - The net effect is that every project is built every day with the latest - version of every dependency - including the latest Ant, latest JUnit, - latest XML parser. - </p> - - <p> - The results are captured into html pages that largely are consistent - with the style of the Jakarta project. An extensive amount of hypertext - links are added to allow quick and easy navigation, and failures are - color coded on the main build page. - </p> - - <p> - A Perl script which is driven off of a naglist will optionally send - e-mails to various newsgroups upon matching strings being found in the - build output. This is typically used to alert developers of build - failures. - </p> - </section> - - <section name="Where is Gump?"> - <ul> - <li><a href="http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/";>Sourc e</a></li> - <li><a href="http://jakarta.apache.org/builds/gump/latest/";>Latest sults</a></li> - <li><a href="http://nagoya.apache.org/~rubys/gump/";>Experimental runs</a></li> - </ul> - </section> - - <section name="When does Gump run?"> - <p> - For Gump to have the desired social affects, it must be predictable. - For now, I have chosen to run Gump daily - with kickoff being midnight - Pacific time. Given the global scale of open source development, there - is clearly no one time when everyone is inactive, but at least this - catches most of the North American continent napping, and is early in - the business day for most of Europe. - </p> - - <p> - Recently, I have been experimenting with a second server kindly donated - by Sun and administered by Pier Fumagalli and Justyna Horwat. After - I'd complained quite a bit, Pier took pitty on me and made available - a LOT of tmp space - backed by 3 gigs of RAM. Doing my builds from - there positively flies!. For now, I've timed - an automated run to be kicked off at noon Pacific time - exactly the - midpoint between "official" runs. Note that I often kick off partial - builds and may even do a full run out of cycle, so the cvs updates logs - may not capture all of the activity that has taken place since the - previous run. - </p> - </section> - - <section name="Who is Gump?"> - <p> - Gump was named after - <a href="http://www.ionet.net/~lesinokc/gump/gump.html";>Forrest Gump</a>, - the title character in a movie. The process for building was to do a - "Generate", followed by cvs "Updates", followed by a "Build All". This - was repetitive, so a command was created to combine these operations - - and it was named "guba". This sound this made when spoken reminded me - of "Bubba Gump". - </p> - - <p> - This seemed oddly appropriate to me as much of the motivation I had - derived from the frustrations I had building a project that I was and - continue to be a big fan of - Cocoon. The - <a href="http://xml.apache.org/cocoon/faqs.html#faq-whyname";>FAQ</a> for - that project indicate that the project was named after a movie that the - creator of that project was particularly fond of, so it seemed fitting - that this effort would be named after a movie that I am fond of. - </p> - - <p> - A number of other fortunate coincidences have convinced me that this - was the right choice for a name. From the role of the feather in the - opening and closing scenes (something I have adapted to the Apache - feature for the Gump icon), to the catch phase of "Stupid is as Stupid - does" - something that captures the spirit of a large number of build - errors caught by this process. And most significantly to me - the - wisdom passed on from Gump's mother that "Life is like a box of - chocolates - you never know what you are going to get!". I can think - of no more apt description of a build process which takes the absolute - latest versions of almost everything and attempts to build them together! - </p> - /section> - -</body> -</document> - +<?xml version="1.0"?> +<document> + + <properties> + <author email="[EMAIL PROTECTED]">Sam Ruby</author> + <title>Gump</title> + </properties> + +<body> + + <section name="What is Gump?"> + + <p> + Gump is a social experiment. The primary goal of Gump is to get diverse + projects to communicate early and often about integration, dependencies, + and versioning management. One way to think about it is that some of the + concepts of + <a href="http://www.extremeprogramming.org/";>Extreme programming</a> + applied to + <a href="http://www.martinfowler.com/articles/continuousIntegration.html";> + Continuous Integration</a> on an unprecedented scale. + </p> + + <p> + Essentially, the reasoning goes like this - if continuous integration is a + good thing on a small project, why not apply it recursively and include all + dependencies for which access to source is provided? + </p> + + </section> + + <section name="How does Gump work?"> + <p> + <a href="http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/project "> + Project</a> definitions are converted from XML to scripts native to the + platform on which you are running. These scripts execute cvs update + commands for every module which contains a project being built, and + invoke builds for each project in an order that ensures that dependencies + are satisfied. + </p> + + <p> + The commands use the actual build.xml files from the projects, but do + not use the scripts or jar files checked into CVS. Instead, the + CLASSPATH is set and properties are passed on the command line. + </p> + + <p> + The net effect is that every project is built every day with the latest + version of every dependency - including the latest Ant, latest JUnit, + latest XML parser. + </p> + + <p> + The results are captured into html pages that largely are consistent + with the style of the Jakarta project. An extensive amount of hypertext + links are added to allow quick and easy navigation, and failures are + color coded on the main build page. + </p> + + <p> + A Perl script which is driven off of a naglist will optionally send + e-mails to various newsgroups upon matching strings being found in the + build output. This is typically used to alert developers of build + failures. + </p> + </section> + + <section name="Where is Gump?"> + <ul> + <li><a href="http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/";>Sourc e</a></li> + <li><a href="http://jakarta.apache.org/builds/gump/latest/";>Latest Results</a></li> + <li><a href="http://nagoya.apache.org/~rubys/gump/";>Experimental runs</a></li> + </ul> + </section> + + <section name="When does Gump run?"> + <p> + For Gump to have the desired social affects, it must be predictable. + For now, I have chosen to run Gump daily - with kickoff being midnight + Pacific time. Given the global scale of open source development, there + is clearly no one time when everyone is inactive, but at least this + catches most of the North American continent napping, and is early in + the business day for most of Europe. + </p> + + <p> + Recently, I have been experimenting with a second server kindly donated + by Sun and administered by Pier Fumagalli and Justyna Horwat. After + I'd complained quite a bit, Pier took pitty on me and made available + a LOT of tmp space - backed by 3 gigs of RAM. Doing my builds from + there positively flies!. For now, I've timed an automated run to be + kicked off at 6 a.m., noon, and 6 p.m. Pacific time - meaning gump runs + occur every six hours. Note that I often kick off partial builds and + may even do a full run out of cycle, so the cvs updates logs on nagoya + may not capture all of the activity that has taken place since the + previous run. + </p> + + <p> + At the same time the "official" run is done on Linux, I've started + some experimentals runs on nagoya. At the moment, this consists of + <a href="http://nagoya.apache.org/~rubys/gump/xerces2";>xerces2</a> and + <a href="http://nagoya.apache.org/~rubys/gump/java14";>java14</a>. + These runs are done with the exact same sources as were used for the + <a href="http://nagoya.apache.org/~rubys/gump/base";>baseline</a> + builds using xerces1 and jdk13. + </p> + </section> + + <section name="Who is Gump?"> + <p> + Gump was named after + <a href="http://www.ionet.net/~lesinokc/gump/gump.html";>Forrest Gump</a>, + the title character in a movie. The process for building was to do a + "Generate", followed by cvs "Updates", followed by a "Build All". This + was repetitive, so a command was created to combine these operations - + and it was named "guba". This sound this made when spoken reminded me + of "Bubba Gump". + </p> + + <p> + This seemed oddly appropriate to me as much of the motivation I had + derived from the frustrations I had building a project that I was and + continue to be a big fan of - Cocoon. The + <a href="http://xml.apache.org/cocoon/faqs.html#faq-whyname";>FAQ</a> for + that project indicate that the project was named after a movie that the + creator of that project was particularly fond of, so it seemed fitting + that this effort would be named after a movie that I am fond of. + </p> + + <p> + A number of other fortunate coincidences have convinced me that this + was the right choice for a name. From the role of the feather in the + opening and closing scenes (something I have adapted to the Apache + feature for the Gump icon), to the catch phase of "Stupid is as Stupid + does" - something that captures the spirit of a large number of build + errors caught by this process. And most significantly to me - the + wisdom passed on from Gump's mother that "Life is like a box of + chocolates - you never know what you are going to get!". I can think + of no more apt description of a build process which takes the absolute + latest versions of almost everything and attempts to build them together! + </p> + </section> + +</body> +</document> + 1.15 +3 -1 jakarta-alexandria/proposal/gump/site/xdocs/status.xml Index: status.xml =================================================================== RCS file: /home/cvs/jakarta-alexandria/proposal/gump/site/xdocs/status.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- status.xml 2001/10/12 10:57:10 1.14 +++ status.xml 2001/10/15 01:52:24 1.15 @@ -23,6 +23,7 @@ received.</p> </subsection> +<!-- <subsection name="xml-fop"> <p>Batik is in the process of correcting what they have described as a fairly fundamental design error. This should only affect a small @@ -30,9 +31,10 @@ affected.</p> <p>At the present time, there is a good line of communication between the two projects, and the fop team understands and agrees to this change. - They have already resynched once, and will try to track to the + They have already resynched twice, and will try to track to the release.</p> </subsection> +--> </section> <section name="Other Issues"> --------------------------------------------------------------------- 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]
