Stefano Mazzocchi wrote: > >> The real question in my mind is - is the information provided by Gump >> useful? > >Yes, much so. But I personally think of Gump taking care of two concerns >at once, and, as today, it doesn't clearly separate them
In calculus terms, the essence of Gump is to observe the system as dt approaches zero. One can deal with an amazing rate of change against an arbitrary large system if the time slice is small enough and the previous slice of the system is known to have worked. > But I think we also need a nightly build system and Gump could easily > (as Sam tells me) provide both, so, why not doing both? > > Gump could build each project twice: the first time (as for nightly > build) with the tagged version of the CVS modules it requires, the > second time, with the head of the CVS. > > Both information is useful and both has value, IMO. Cool. I'll do the former. Still looking for a volunteer to do the latter. If batik does not want to maintain backwards compatibility, and fop continues to rely on unsupported interfaces, then I'll leave it to others to prove that there exists some combination of versions that might actually work. Note: I do build two versions of soap, turbine, tomcat, and xerces today. I used to build two versions of cocoon and xalan. I even do additional runs with jdk 1.4 and xerces 2. Also note that I don't do this casually: soap2, turbine2, tomcat3, and xerces1 are still actively being maintained. - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
