From: Sam Ruby (23 May 2001 10:02 AM)
> 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...
(Disclaimer: I'm not a committer on any project, so my opinion is
objective, but slightly under-informed, and without authority)
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.
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.
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.
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.
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.
Potentially, you could have gump work in a system where if a project
fails a build, it moves to nightly builds only, but onces it passes
a nightly build it moves to a build every 3(?) hours, until it fails
again.
That way, you're not going to keep getting "build failed" messages
all days, waiting for someone to fix it, but you will know straight
away (alomost) when a change breaks a project.
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).
Anyway, the conclusion I can see is that for reasons 1-3, gump is
actually replacing build/testing on developers machines, and is
generally being the method by which people are alerted that they broke
something, rather than them discovering it themselves.
I don't think that this is a problem, but it will mean that gump is
going to keep failing.
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.
JM2C.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
