Vincent Massol wrote:
>>How will this program solve the problem of people not caring about
>>the build being broken?
>>
> It doesn't! What it does is remove the "problem" in the first place :-)
What is the problem exactly? That the build is broken? It's still broken
after this, but now its not checked in.
What exactly does it mean to say that the build is broken? What is the cost
of a broken build? The answer: other people shouldn't try to do integration
while the build is broken, as they would need to fix the error first to
ensure that they don't have any errors.
If you use an "integration token" approach, then you haven't finished
integrating until you get a successful build. If there's a couple of broken
builds in the process, is that a big deal? Not really: nobody else should
have tried integrating, so they shouldn't have been impacted.
If you have a larger team, with subsequently more people trying to
integrate in a given time frame, then you need to take a different approach
to a broken build. What you probably need to do is some sort of diagnosis
approach with all the impacted developers, then have one developer (or
pair) take responsibility for getting the build good again. This shouldn't
be a long process; if people are committing regularly and at least running
the tests locally, most errors will be fairly small in magnitude.
The real "cost" of a broken build is a social factor that will vary from
team to team.
Robert.
--
"Software is too expensive to build cheaply"
Robert Watkins http://twasink.net/ [EMAIL PROTECTED]
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
