----- Original Message -----
From: David Jencks <[EMAIL PROTECTED]>
> Aside from using cruise control, how does this differ from what chris
> kimpton already has set up(http://www.lubega.com/), which runs the
> testsuite at least once a day and I think does hourly builds?  How does
> your proposed system distinguish a broken build from a lengthy multi-part
> checkin where writing the comments on the next chunk takes 10 minutes?

CruiseControl has a "quiet period" which means that it waits for a developer to stop 
checking in code before it starts it's build. Once no checkins have been detected for 
x amount of minutes, then the build starts. 

I've been the build master for Java projects with 700k loc and 50+ developers all 
actively checking in and it is extremely rare that the build starts mid checkin. When 
it does, it usually fixes itself within a few minutes.  

CruiseControl differs in that it ties the build to checkins, so you can very easily 
address accountability for broken builds. The web page that is generated will give you 
a list of files that were checked om. More importantly, there are names attached to 
those files, so you can very easily see who checked in Foo.java that does not compile 
or SimpleTest.java that fails. 

In a big project when tests break, accountability needs to be established and quickly 
- and this means when, how, and who. Broken windows cannot be tolerated whatsoever. 

Although, http://lubega.com will tell you what is broken, and approximately when it 
was broken. It can't link the broken build to a specific checkin and ultimately to the 
offending party. 

> 
> How would your system apportion blame when there are several checkins at
> the same time (either interlaced or within less time than it takes to
> checkout and do a clean build) and the build breaks?

The system cannot be perfect, and tell you exactly who broke what, especially with 
interlaced checkins. However, these situations are often rare, and continuous 
integration with CruiseControl will give you enough information that you can figure 
out what happened and solve the problem within a few minutes. I've been in these 
situations before, and its never taken me more than 15 minutes to trace through the 
CruiseControl logs and find the offending developer within a few minutes. 

Hope this helps.

Mike
-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to