----- Original Message -----
From: "Dominique Devienne" <[EMAIL PROTECTED]>
To: "'Ant Users List'" <[EMAIL PROTECTED]>
Sent: Thursday, October 17, 2002 12:30 PM
Subject: RE: Looking for a Build Philosophy
> Sadly, I'd have to concur with Scott. Treats are not enough, especially in
a
> distributed environment where people are in at least 3 cities, if not
> working from home.
yes, but hooking up those electric shock pet collars to the serial port,
then forcing people to run a web service at their homes to enable it is both
technically hard and illegal :)
One of the best punishments for having people break the build is make them
fix it. Anything that reduces the time between check in to 'awareness of
break and identification of culprit' is is great, which is where continuous
integration tools come in.
Sadly, in a world where you need nightly builds of things like Apache Axis,
you also depend upon the willingness of developers round the world not to
break your build, a build they dont know or care about. You can stick to
monthly or point releases, but then every month or release struggle to
discover what broke. Or you can hook off the CVS_HEAD repositories, take the
pain and at least get to notify the relevant teams whenever they create a
regression.
Find a bug in an OSS project the day after it is introduced, it gets fixed.
Find it the day after the product gets released, it gets fixed a lot later.
>We have all the right intention/process in place,
> published, etc... and still people don't write test, and half the time
write
> so-so code. Thankfully we have nightly builds and CruiseControl running,
and
> things have settled down a bit, but the carrot is not enough in my mind,
and
> the stick should have been handled more often than not. I'm afraid nothing
> will ever replace good personal code hygiene, except perhaps true XP with
> pair programming to learn from your peers, and have them look over your
> shoulder half the time.
Maybe that's the secret of XP: pair programming means there is someone there
to stop you typing bad code the moment they see it.
The hardest barriers in a past project of mine was
-getting the test developers to adopt ant as the build tool for their
sub project
-building all the legacy win32 stuff.
--
To unsubscribe, e-mail: <mailto:ant-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@;jakarta.apache.org>
