Re: Status?
David Crossley [EMAIL PROTECTED] wrote on 03/06/2007 08:32:49 PM: [EMAIL PROTECTED] wrote: By the way - I am also interested in the Apache Depot project that is linked to from the Gump page. Unfortunately there is no code or even developer email addresses on the page as it is in incubation. Any idea when this will be available? Does Gump use it? The Apache Incubator project Depot did not survive the incubation process: http://incubator.apache.org/projects/#Retired+from+incubation http://incubator.apache.org/projects/depot.html There are probably guidelines at the Incubator website if you want to build a community around it and revive it. Discuss on the general at incubator list. -David Thanks for the update. Mark. AMI Semiconductor - Silicon Solutions for the Real World NOTICE: This electronic message contains information that may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.
Re: Status?
Hi Leo, Thanks for the reply. I'll give Gump2 a closer look then. By the way - I am also interested in the Apache Depot project that is linked to from the Gump page. Unfortunately there is no code or even developer email addresses on the page as it is in incubation. Any idea when this will be available? Does Gump use it? Thanks, Mark. Leo Simons [EMAIL PROTECTED] wrote on 03/03/2007 02:54:53 PM: Hey Mark! On Mar 2, 2007, at 9:10 PM, [EMAIL PROTECTED] wrote: I've been doing requirements and design for a build system and continuous integration setup for our in-house software and on the build side I have made the rounds from Maven2+Ant to Ivy+Ant to commercial systems to a home-brew system. Currently we use a lot of Ant and make, and some other stuff. In the process of all this I looked at Gump briefly and moved on. Now that I am thinking more about how I would design a system to build all of our projects (using Ant) it was starting to slightly resemble Gump and its approach using modules and projects. I am now looking at it again in more detail and I like what I see so far (and I love Python so that rocks too). I was wondering what the current status of the project is. I see stuff about Gump3 in development and I am intrigued. If I wanted to start using it is Gump3 ready for primetime? I find surprisingly little info on the project in terms of other people using it outside of Apache. I was wondering if that meant it was relatively dead, or it just works so well that nobody talks about it? ;o) Any advice would be most welcome. Thanks for your interest. I would say Gump3 is currently in hybernation, unfortunately. Not dead, since I do still plan to return to work on it at some point in the future, but right now it is just not functionally complete nor ready for real use. Gump2 is still running at apache and elsewhere though, and working just fine, even if its not seeing that much active development either right now. Unless you want to dive in and hack Gump3 into something production-ready yourself, I'd suggest starting off from the gump2 configuration in use at apache and customizing it for your own use. cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] AMI Semiconductor - Silicon Solutions for the Real World NOTICE: This electronic message contains information that may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.
Re: Status?
Hey Mark! On Mar 2, 2007, at 9:10 PM, [EMAIL PROTECTED] wrote: I've been doing requirements and design for a build system and continuous integration setup for our in-house software and on the build side I have made the rounds from Maven2+Ant to Ivy+Ant to commercial systems to a home-brew system. Currently we use a lot of Ant and make, and some other stuff. In the process of all this I looked at Gump briefly and moved on. Now that I am thinking more about how I would design a system to build all of our projects (using Ant) it was starting to slightly resemble Gump and its approach using modules and projects. I am now looking at it again in more detail and I like what I see so far (and I love Python so that rocks too). I was wondering what the current status of the project is. I see stuff about Gump3 in development and I am intrigued. If I wanted to start using it is Gump3 ready for primetime? I find surprisingly little info on the project in terms of other people using it outside of Apache. I was wondering if that meant it was relatively dead, or it just works so well that nobody talks about it? ;o) Any advice would be most welcome. Thanks for your interest. I would say Gump3 is currently in hybernation, unfortunately. Not dead, since I do still plan to return to work on it at some point in the future, but right now it is just not functionally complete nor ready for real use. Gump2 is still running at apache and elsewhere though, and working just fine, even if its not seeing that much active development either right now. Unless you want to dive in and hack Gump3 into something production-ready yourself, I'd suggest starting off from the gump2 configuration in use at apache and customizing it for your own use. cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of xalan breakage?
On Thu, 06 Jan 2005, Leo Simons [EMAIL PROTECTED] wrote: Please see http://gump.apache.org/metadata/project.html#jar It sounds like 'type=boot' needs to be added to the xalan descriptor somewhere. Probably we need work with type=boot for a thing like this, but even then we'd need to guarantee that Xalan's classes dir comes in front of xml-apis.jar. I've seen that build.sysclasspath has been turned off now, but I haven't caught up with my mails and current Gump runs yet. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of xalan breakage?
Hi all! On 04-01-2005 20:00, Christine Li [EMAIL PROTECTED] wrote: Hello, To figure out whether build.sysclasspath has been changed recently, I found that on the gump main page under How does Gump work[1], it says Note Gump set's Ant's build.sysclasspath to only and manages the system classpath . So I was wrong in my previous email, we should keep build.sysclasspath=only and add /usr/local/gump/public/workspace/xml-xalan/java/build/classes to the bootclasspath setting. Can someone works on Gump correct it? Or if it is something that I can change from xml-xalan site, please let me know. Thanks, Please see http://gump.apache.org/metadata/project.html#jar It sounds like 'type=boot' needs to be added to the xalan descriptor somewhere. Christine, all ASF committers have write access to the gump cvs repository so you can easily correct it yourself (we *all* work on gump :-D). Simply cvs -d $APACHE_REPO co gump -P cd gump/project $EDITOR xml-xalan.xml # or xml-xalan2, I dunno, there's a file there # change the descriptor cvs commit -m useful description goes here And that's it! Best regards, Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of xalan breakage?
Hi, Leo Thanks for pointing me to a solution for fix the xalan build. However, I found there is not a type attribute for work. In order to build xalan-unbundled.jar with JDK1.4, we need to add %Xalan-workspace%/build/classes to the boot classpath. (Assume that build.sysclasspath=only). Did I miss anything or is there any other solution without changing the build.sysclasspath setting? Thanks, Christine Li XSLT Development IBM Toronto Lab Tel: (905)413-2601 Email: [EMAIL PROTECTED] Leo Simons [EMAIL PROTECTED] 01/06/2005 06:11 AM To Gump code and data general@gump.apache.org cc Christine Li/Toronto/[EMAIL PROTECTED] Subject Re: status of xalan breakage? Hi all! On 04-01-2005 20:00, Christine Li [EMAIL PROTECTED] wrote: Hello, To figure out whether build.sysclasspath has been changed recently, I found that on the gump main page under How does Gump work[1], it says Note Gump set's Ant's build.sysclasspath to only and manages the system classpath . So I was wrong in my previous email, we should keep build.sysclasspath=only and add /usr/local/gump/public/workspace/xml-xalan/java/build/classes to the bootclasspath setting. Can someone works on Gump correct it? Or if it is something that I can change from xml-xalan site, please let me know. Thanks, Please see http://gump.apache.org/metadata/project.html#jar It sounds like 'type=boot' needs to be added to the xalan descriptor somewhere. Christine, all ASF committers have write access to the gump cvs repository so you can easily correct it yourself (we *all* work on gump :-D). Simply cvs -d $APACHE_REPO co gump -P cd gump/project $EDITOR xml-xalan.xml # or xml-xalan2, I dunno, there's a file there # change the descriptor cvs commit -m useful description goes here And that's it! Best regards, Leo
Re: status of xalan breakage?
Hello, To figure out whether build.sysclasspath has been changed recently, I found that on the gump main page under How does Gump work[1], it says Note Gump set's Ant's build.sysclasspath to only and manages the system classpath . So I was wrong in my previous email, we should keep build.sysclasspath=only and add /usr/local/gump/public/workspace/xml-xalan/java/build/classes to the bootclasspath setting. Can someone works on Gump correct it? Or if it is something that I can change from xml-xalan site, please let me know. Thanks, [1]http://gump.apache.org/#How+does+Gump+work%3F Christine Li XSLT Development IBM Toronto Lab Tel: (905)413-2601 Email: [EMAIL PROTECTED]
Re: status of xalan breakage?
On 02-01-2005 22:32, Brett Porter [EMAIL PROTECTED] wrote: any objections to me doing this? Not from me! - Leo 1) create a xalan-failing project that uses xalan HEAD to build 2) make the xalan descriptor either package the last release, or build from a known-good tag 3) when xalan-failing starts building again, switch back - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of xalan breakage?
Hi, I investigated the failed gump build for xml-xalan before I went on vacation. From the error message, it looks like that there are some classpath setting issues. I have no objections to your temporary solution and I would like to collaborate to get this problem resolved as a developer for xalan. I have no problem to build Xalan Head with both Sun JDK1.4.0_03 on Windows2000 (and the nightly ant build) as an independent project. Because of lack of information about the nightly gump build, I don't know what I can do at this moment. Would you please let me know how I can reproduce the failed build? 1. version of JDK 2. jar files on the bootclasspath 3. jar files and classes on classpath, etc. 4. Is there anyway that I can access archive of the gump build? Any suggestions would be appreciated. Thanks, Original Message from Brett Porter [EMAIL PROTECTED] any objections to me doing this? 1) create a xalan-failing project that uses xalan HEAD to build 2) make the xalan descriptor either package the last release, or build from a known-good tag 3) when xalan-failing starts building again, switch back Christine Li XSLT Development IBM Toronto Lab Tel: (905)413-2601 Email: [EMAIL PROTECTED]
Re: status of xalan breakage?
any objections to me doing this? 1) create a xalan-failing project that uses xalan HEAD to build 2) make the xalan descriptor either package the last release, or build from a known-good tag 3) when xalan-failing starts building again, switch back On Wed, 29 Dec 2004 23:03:40 +1100, Brett Porter [EMAIL PROTECTED] wrote: Hi, I notice xalan has been broken for two weeks. I've seen a couple of enquiries here, but am not sure of the status. Is anyone working on fixing this? It's knocked out half of the projects :) I'd like to get directory finalised (which depends on this), and would also like to move commons-jelly to a maven build instead of its generated ant descriptors, but it won't build until xalan does either. Is it possible to do this: 1) create a xalan-failing project that uses xalan HEAD to build 2) make the xalan descriptor either package the last release, or build from a known-good tag 3) when xalan-failing starts building again, switch back This is a highly manual but cheap way of doing last good :) WDYT? Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [status] main issues
On Thursday 07 October 2004 21:37, Stefano Mazzocchi wrote: The problem with maven is that I don't know how we can inject the gump-generated dependency jars into maven. Brett Porter (Maven expert) is normally around to answer questions on how Maven operates. Does anybody have an idea? we can't expect excalibur to fix this on their own since this is obviously a gump issue, more than an excalibur issue. I can propose a short term solution; Revert the Excalibur packages in Gump back to the one sitting in the frozen avalon-excalibur CVS, which builds close to perfectly in Gump (I think there is the altrmi instrumentation packages that fails as a dep on altrmi, or something like that.) Then we take the Excalibur Maven projects and name them slightly different, so we can sort that out without holding up all the projects downstream. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [status] main issues
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] But the *most* serious concern is that we seem to have no way to build with Maven and, due to excalibur, this is holding up basically 15 percent of our projects (including, yes, you guessed right, cocoon). Fast track solution could be to put the last released jar files into an excalibur-releases module with project ids matching the current set of ids, and disable the existing excalibur descriptors pending resolution of gump/maven equation (see below). The problem with maven is that I don't know how we can inject the gump-generated dependency jars into maven. Maven is fine on the injection stuff - basically it used a jar override property that tells maven to use the jar file named in a property value as the actual jar to bind against. The problem is the generation of the property files (by gump's maven builder). Does anybody have an idea? Gump uses a namespace made of a project id and an optional output key. Maven uses a combination of group and artifact name combination. If we take for example - the jar file produced by ant containing the junit optional task is referenced in gump as: project: ant id: junit In Maven the same jar file is normally referenced as: groupId: ant artifactId: ant-junit When Gump's maven builder generates the proprieties file used during the maven build, it uses the gump project model to establish the set of dependencies and for each dump declared dependency (with full inheritance of dependencies) create a property with the following name and value: maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit. jar Problem here is that: 1. this property definition does not correspond to anything declared in the target project's project.xml (because the property is derived from the gump based dependencies - not the project's declared dependencies) 2. the strategy for mapping of gump artifact keys to maven artifact keys is basically broken in that duplicate property names can be generated (e.g. the property name generated for the main JUnit project jar file is maven.jar.junit) The solution to this problem is to drive the property file generation off the project.xml file and NOT the gump dependency graph. This will solve most issues because it will result in a much smaller set of properties - but an underlying problem needs to be solved - namely the declaration within a maven project of any mappings between maven artifact names to gump project keys (e.g. ant/ant-junit -- ant:junit). These mappings need to be used by the maven gump task when generating a maven project descriptor. Stephen. we can't expect excalibur to fix this on their own since this is obviously a gump issue, more than an excalibur issue. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [status] main issues
Stephen, thanks much for your input. Some comments below. But the *most* serious concern is that we seem to have no way to build with Maven and, due to excalibur, this is holding up basically 15 percent of our projects (including, yes, you guessed right, cocoon). Fast track solution could be to put the last released jar files into an excalibur-releases module with project ids matching the current set of ids, and disable the existing excalibur descriptors pending resolution of gump/maven equation (see below). Yes, that might be an ad-hoc solution and it might work for now since there are not so many maven projects in our tree anyway (just checked). Can you provide such a 'fake' descriptor? i think it would be much faster than me trying to hack one up. The problem with maven is that I don't know how we can inject the gump-generated dependency jars into maven. Maven is fine on the injection stuff - basically it used a jar override property that tells maven to use the jar file named in a property value as the actual jar to bind against. The problem is the generation of the property files (by gump's maven builder). Ok, good to know. Does anybody have an idea? Gump uses a namespace made of a project id and an optional output key. Maven uses a combination of group and artifact name combination. If we take for example - the jar file produced by ant containing the junit optional task is referenced in gump as: project: ant id: junit In Maven the same jar file is normally referenced as: groupId: ant artifactId: ant-junit When Gump's maven builder generates the proprieties file used during the maven build, it uses the gump project model to establish the set of dependencies and for each dump declared dependency (with full inheritance of dependencies) create a property with the following name and value: maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit. jar Problem here is that: 1. this property definition does not correspond to anything declared in the target project's project.xml (because the property is derived from the gump based dependencies - not the project's declared dependencies) 2. the strategy for mapping of gump artifact keys to maven artifact keys is basically broken in that duplicate property names can be generated (e.g. the property name generated for the main JUnit project jar file is maven.jar.junit) The solution to this problem is to drive the property file generation off the project.xml file and NOT the gump dependency graph. This will solve most issues because it will result in a much smaller set of properties - but an underlying problem needs to be solved - namely the declaration within a maven project of any mappings between maven artifact names to gump project keys (e.g. ant/ant-junit -- ant:junit). These mappings need to be used by the maven gump task when generating a maven project descriptor. I'm sorry, but I have lost you. If the strategy is broken, why don't we fix it? [but I think I'm missing a point here obviously] -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [status] main issues
3) the maven integration is poor and hacky How much do you actually know about this integration? I don't know that it is poor, and I believe it is not hacky. Where are you getting your information? But the *most* serious concern is that we seem to have no way to build with Maven and, due to excalibur, this is holding up basically 15 percent of our projects (including, yes, you guessed right, cocoon). The problem with maven is that I don't know how we can inject the gump-generated dependency jars into maven. We are doing it. Clearly you've next to no idea on how this works. We use the technique that Mavenites told us was appropriate: http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependencies Does anybody have an idea? we can't expect excalibur to fix this on their own since this is obviously a gump issue, more than an excalibur issue. So what is the problem? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [status] main issues
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] But the *most* serious concern is that we seem to have no way to build with Maven and, due to excalibur, this is holding up basically 15 percent of our projects (including, yes, you guessed right, cocoon). Fast track solution could be to put the last released jar files into an excalibur-releases module with project ids matching the current set of ids, and disable the existing excalibur descriptors pending resolution of gump/maven equation (see below). The problem with maven is that I don't know how we can inject the gump-generated dependency jars into maven. Maven is fine on the injection stuff - basically it used a jar override property that tells maven to use the jar file named in a property value as the actual jar to bind against. The problem is the generation of the property files (by gump's maven builder). Does anybody have an idea? Gump uses a namespace made of a project id and an optional output key. Maven uses a combination of group and artifact name combination. If we take for example - the jar file produced by ant containing the junit optional task is referenced in gump as: project: ant id: junit In Maven the same jar file is normally referenced as: groupId: ant artifactId: ant-junit When Gump's maven builder generates the proprieties file used during the maven build, it uses the gump project model to establish the set of dependencies and for each dump declared dependency (with full inheritance of dependencies) create a property with the following name and value: maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit. jar Problem here is that: 1. this property definition does not correspond to anything declared in the target project's project.xml (because the property is derived from the gump based dependencies - not the project's declared dependencies) 2. the strategy for mapping of gump artifact keys to maven artifact keys is basically broken in that duplicate property names can be generated (e.g. the property name generated for the main JUnit project jar file is maven.jar.junit) The solution to this problem is to drive the property file generation off the project.xml file and NOT the gump dependency graph. This will solve most issues because it will result in a much smaller set of properties - but an underlying problem needs to be solved - namely the declaration within a maven project of any mappings between maven artifact names to gump project keys (e.g. ant/ant-junit -- ant:junit). These mappings need to be used by the maven gump task when generating a maven project descriptor. Stephen. we can't expect excalibur to fix this on their own since this is obviously a gump issue, more than an excalibur issue. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [status] main issues
Adam R. B. Jack wrote: So what is the problem? Problem is http://brutus.apache.org/gump/public/excalibur/ maven integration might not be hacky (true, I had no idea we were injectin stuff in, so I take that back) but it does not work at all. Now, tell me, is this just a matter of fixing the excalibur.xml file or, like Stephen suggested, the problem is much deeper? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: status blogging
Anything you can do from python can be done via CGI. Anything. Ahhh, reminds me of CGI.pm (and oh the fun I used to have with that :-). I hear you. Hey, I won't -1 any webapp contribution, CGI, framework or otherwise. I think there is Gump Gold in that direction, and feel that any step there is worthy... regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status blogging
yeah, sams weblog package and ViewSVN :-D. Zope is something I totally don't understand on looking a little closer, for example. I mean, there's a ***class*** named Interface! I am a big turd when it comes to python. I can write like 3 lines of code in one go and then things start breaking. Yeah, it takes a while to get into, doesn't it. Replacing Java thinking for Pythonic is hard, and I know I've not acheived it (in any sense) yet. Running pychecker on Gump shows that for a fact... ;-) I would just love to see how Sam sets this up. I think you already did. ;-) Lean and mean. :-) regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status blogging
Leo Simons wrote: Stephen McConnell wrote: Adam R. B. Jack wrote: 4) The 'root cause/resolution' for outage X/Y (between too parties) was Z. Log it/Blog it... ++1 If this was available I would definitely use it to post details about what is going on relative to the projects I'm associated with. Furthermore - it would provide an extra hint that there is someone somewhere dealing with a problem as opposed to waiting n days for a change in status - which is something I would find really valuable in terms of projects I'm dependent on. you know, we do have one of the authorities on blogging and syndication right here as a resident gump meister. Someone who happens to know python rather well to boot. And someone who's itching to write code according to his blog... The hardest thing is authentication (something that the peascarrots blog sidesteps nicely via CVS). Starting long running tasks is made possible by platforms that support fork (sorry Windows). Beyond those two the next biggest hurdle is the markup that is produced. If that is relatively straightforward (in other words, uses techniques like CSS instead of things like spacer gifs and nested tables), then building CGIs is downright trivial. If we can settle on an authentication mechanism, and agree to not worry about Windows initially, and get a clean CSS-based skin for gump pages, I can start picking off tasks from Adam's original list. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [status] me and gump
Adam R. B. Jack wrote: 4) The 'root cause/resolution' for outage X/Y (between too parties) was Z. Log it/Blog it... ++1 If this was available I would definitely use it to post details about what is going on relative to the projects I'm associated with. Furthermore - it would provide an extra hint that there is someone somewhere dealing with a problem as opposed to waiting n days for a change in status - which is something I would find really valuable in terms of projects I'm dependent on. Cheers, Steve. -- || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/merlin/distributions/latest| || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
status blogging (was: Re: [status] me and gump)
Stephen McConnell wrote: Adam R. B. Jack wrote: 4) The 'root cause/resolution' for outage X/Y (between too parties) was Z. Log it/Blog it... ++1 If this was available I would definitely use it to post details about what is going on relative to the projects I'm associated with. Furthermore - it would provide an extra hint that there is someone somewhere dealing with a problem as opposed to waiting n days for a change in status - which is something I would find really valuable in terms of projects I'm dependent on. you know, we do have one of the authorities on blogging and syndication right here as a resident gump meister. Someone who happens to know python rather well to boot. And someone who's itching to write code according to his blog... -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ Component Community -- http://componentplanet.org/ Component Glue -- http://jicarilla.org/ --- 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]
blog Re: [status] me and gump
Stephen McConnell wrote: Adam R. B. Jack wrote: 4) The 'root cause/resolution' for outage X/Y (between too parties) was Z. Log it/Blog it... ++1 If this was available I would definitely use it to post details about what is going on relative to the projects I'm associated with. Furthermore - it would provide an extra hint that there is someone somewhere dealing with a problem as opposed to waiting n days for a change in status - which is something I would find really valuable in terms of projects I'm dependent on. Gump has a blog called Peas and Carrots at http://gump.chalko.com/gb/blog/ Any one can add post by committing a file to CVS. at gump/blog/ Copy the file http://cvs.apache.org/viewcvs.cgi/gump/blog/Template.txt?view=markup and edit as needed. R, Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
