Re: [GUMP] Build Failure - Turbine
Jason van Zyl wrote: What is going on here? I fixed this code almost two days ago. http://jakarta.apache.org/builds/gump/2001-05-21/cvs_index.html http://jakarta.apache.org/builds/gump/2001-05-22/cvs_index.html Compare this to the good old days: http://jakarta.apache.org/builds/gump/2001-04-15/cvs_index.html Daedalus performance (or lack thereof) has basically gotten to the point where programs like Gump are great in theory, but impractical in practice... - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Turbine
Tim Vernum wrote: In general, I believe that automated build/test processes are *very* important, an do work. We've got some teams using CruiseControl here, and it is doing well. The reasons I think that gump registers so many failures are: 1) The environment in which gump runs is not identical to the environment the developers run (OS, jdk, jars, etc), and I'm not sure if it is even well defined. Now, given that these are supposed to be cross platform java projects, that shouldn't be an issue, but it has been, and will continue to be. When has it been? If an OS issue is found, Gump did its job. The 'cross HEAD CVS', which is how i think of Gump, does something that developers don't do, but should have done for them - which is early detection of interface-ish problems. There is nothing (other than the sloth of Daedalus) which prevents us from adding any 'test' we want - Gump is running the Velocity testbed, for example, which is more than interface-related, but functional as well. I once thought it important to setup Gump tests that specify a specific version set (i.e. the release versions of all dependencies), but I realize that's pointless. Do the test once, and repeating can add no new information. Unless each developer replicates the Gump environment on his/her workstation, they will not find all problems. However doing so will only fix problems for that environment, so in some ways leaving it slightly undefined is helpful to keep portability. Yes. 2) Developers can't/don't run the tests before checkin. In our situation, if you checkin something that breaks the tests, you're an idiot. I don't think that happens in apache, for a few reasons. The primary one being that most people are doing this in the spare time, and a channeling in patches from numerous sources. Forcing full rebuilds with unit tests would make that channel so small that work would grind to a virtual stand-still. Not sure I buy this - Velocity has a unit test suite that has saved us (me) in countless instances, so I know if a change has altered the gross functional envelope that we have been able to define. 3) Developers can't/don't test other projects. This is particularly relevant to ant, but also to some of the XML and (soon) commons modules. A number of build failures have been due to changes in ant. Ant should continue to be free to change things as needed to make ant better, and that will continue to break projects that rely on specific ant features/bugs. Unless the developers are going to rebuild all the dependant projects everytime they make a change, then this will keep happening. Interesting topic : like any other released package/project/tool with users, does Ant ensure that it is backwards compatible with itself, at least on major version boundaries? (I think it should be...) [SNIP] 5) Attitude. Given the length of time that some projects remain broken, I guess some projects don't particularly care too much. Which is a pity. (Granted some projects believe they've fixed it, and that gump is misbehaving, so you can't blame them for that). I think if it gets repositioned to fill such a role (or maybe it already is, and I'm misinformed) then solving (4) will be useful. Ultimately though, (5) is the kicker. That's a matter of resources for (4) and time and social engineering for (5), I think. With an all volunteer group, I think it has to be worked into the culture. While you could force the issue by making it a part of being a Jakarta project, I don't think we want to do that. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ still climbing up to the shoulders... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Turbine
Geir Magnusson Jr. wrote: There is nothing (other than the sloth of Daedalus) which prevents us from adding any 'test' we want - Gump is running the Velocity testbed, for example, which is more than interface-related, but functional as well. That test suite takes 58 seconds to run. I think we can afford that. In any case, it runs on my machine, not on Daedalus. I once thought it important to setup Gump tests that specify a specific version set (i.e. the release versions of all dependencies), but I realize that's pointless. Do the test once, and repeating can add no new information. ;-) That's a matter of resources for (4) and time and social engineering for (5), I think. With an all volunteer group, I think it has to be worked into the culture. While you could force the issue by making it a part of being a Jakarta project, I don't think we want to do that. This is happening. Six months ago several key projects were in perpetual alpha, and there was very little code sharing. And Gump was just a concept. Six months later, look at how things have changed. The mere thought that somebody might not have addressed a problem 48 hours after it was detected is being raised as an issue... Gump and I are happy. ;-) - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [GUMP] Build Failure - Turbine
3) Developers can't/don't test other projects. This is particularly relevant to ant, but also to some of the XML and (soon) commons modules. A number of build failures have been due to changes in ant. Ant should continue to be free to change things as needed to make ant better, and that will continue to break projects that rely on specific ant features/bugs. Unless the developers are going to rebuild all the dependant projects everytime they make a change, then this will keep happening. Interesting topic : like any other released package/project/tool with users, does Ant ensure that it is backwards compatible with itself, at least on major version boundaries? (I think it should be...) I think the Ant team take backward compatability very seriously. Nevertheless, sometimes a change is introduced, which, although unintended, does cause compatability issues. We track Gump closely to catch these unintended problems and try to resolve them as quickly as practical. Sometimes we make a change which will flush out problems in build files. Is that a backward compatability issue? The recent copying of non-existent files is an example. A number of builds broke because Ant tightened up one of its checks. What level of backward compatibility are we looking for. Should we preserve bugs so that nobody ever has to change a build file. I'd be interested in viewpoints there. Sometimes, even deprecating things in Ant causes complaints :-) As Gump is using CVS snapshots we should expect Gump to fail - this is its benefit. We should be happy when it fails :-) Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Turbine
Sam Ruby wrote: Geir Magnusson Jr. wrote: There is nothing (other than the sloth of Daedalus) which prevents us from adding any 'test' we want - Gump is running the Velocity testbed, for example, which is more than interface-related, but functional as well. That test suite takes 58 seconds to run. I think we can afford that. In any case, it runs on my machine, not on Daedalus. No - what I meant was adding to the gump cycle time by adding more CVS activity to the mix. I figured that the CVS is the bottleneck - you can always parallelize the gumping once the source is there, although I suspect you won't need to :) That's a matter of resources for (4) and time and social engineering for (5), I think. With an all volunteer group, I think it has to be worked into the culture. While you could force the issue by making it a part of being a Jakarta project, I don't think we want to do that. This is happening. Six months ago several key projects were in perpetual alpha, and there was very little code sharing. And Gump was just a concept. Six months later, look at how things have changed. The mere thought that somebody might not have addressed a problem 48 hours after it was detected is being raised as an issue... Gump and I are happy. It's never clear to me that they are distinct entities ;) geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ still climbing up to the shoulders... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
