Tim Vernum wrote:
>
> 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.
It is well defined, and you can even run it yourself. Loosely, it can be
described as "the latest CVS of everything possible."
> 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.
This doesn't apply here...however your next point does.
> 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.
> Unless the developers are going to rebuild all the dependant
> projects everytime they make a change, then this will keep
> happening.
In practice, it isn't practical for turbine developers to test every change
to every dependency that they have the instant that product makes a change.
In practice, it isn't practical for velocity developers to test every
change they make against every product or potential product which may use
their code.
That's why Gump is there - as a valuable (though not infallible) cross
check. Note: I do fully intend to keep up with the developments of
xml-commons as they become available.
> 4) Gump (I think) only runs once a day.
> This means that there's up to 24hrs before you know that you broke
> something.
> CruiseControl (generally) runs every 15 minutes, and rebuilds if
> the project has had a new checkin. This way you know quite quickly
> that you broke something.
Given the current performace of the Apache server, it has taken up to
twelve hours to get the updates to the latest projects - and that is only
after killing off updates that take more than a half an hour! Last month I
had days where I could update every project in as little at 35 minutes!
> 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).
This is grossly unfair, and the real reason why I took the time to respond
to this note.
JVZ promptly addressed the root problem (I have verified the change on my
own machine). Unfortunately, this change is not reflected in Gump because
for two days straight, I have been unable to successfully do an cvs update
for the projects in question in the time allotted.
And if I can't successfully update a single project, no tool which runs
every 15 minutes would have a chance...
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
