[p4] Enforcing "code chill" - Chuck Karish - com.perforce.perforce-user

9 messages in com.perforce.perforce-user[p4] Enforcing "code chill"

From	Sent On	Attachments
Jim Crossley	24 Oct 2003 08:47
Todd Short	24 Oct 2003 09:13
Dave Lewis	24 Oct 2003 09:23
Jim Crossley	24 Oct 2003 09:46
Stephen Vance	24 Oct 2003 16:03
Jim Crossley	24 Oct 2003 17:01
Jeff Bowles	06 Nov 2003 20:24
Chuck Karish	07 Nov 2003 06:40
Stephen Vance	07 Nov 2003 10:23

Subject:	[p4] Enforcing "code chill"
From:	Chuck Karish (kar...@well.com)
Date:	11/07/2003 06:40:26 AM
List:	com.perforce.perforce-user

At 08:25 PM 11/6/2003 -0800, Jeff Bowles wrote:

From: Jim Crossley <jim at crossleys.org> I've read that paper (and many others, including yours :-). The "code chill" idea came from Chuck Walrad's paper (http://www.unilog-itservices.ch/Seapine/Documents/SCMBranchingModels.pdf) describing the "Branch-by-Purpose" model. I like the idea of fixing bugs in the mainline during code chill instead of the qc releases to minimize the merging. Why is that not a good idea?

As Jeff says, it reduces your ability to manage the code line. If one of the bug fixes turns out to be more difficult than expected, the release process stalls. A compromise that works well is to allow maintenance on the main line (or directly on the release candidate branch) only for bug fixes without which the product will definitely not ship.

The most useful thing I've done, at this stage, is to make a graph with the two codelines (parent/child, main/release, whatever) and clearly WRITE DOWN the exact "purpose" for each codeline. One is pristine or slow-moving, the other is faster-moving but less-proven.

And write down the purpose where the developers can find it. Like, for instance, in the Description: field of the branch spec, in addition to putting it in your development process documentation.

But I pretty much ALWAYS build a QA/test/release/etc version out of a branched copy. I figure, it's better to build out of the branch for the final versionsof any release, because that can be the branch that patches will eventually be built from, also. As a result, the QA process is proving the release *and* the patch-line that will eventually support the release.

I say this every day - test the bits you're going to ship, check and recheck the results of your merges with diff as well as with p4 diff, NO you can't count on QA to make sure you haven't made any merge errors, and on and on.

For releases the rule of thumb is to branch as late as possible and as soon as necessary.