IBM SC34-4499-03 manual States of work areas, Approve state, Fix state

The states of work areas

A work area is a storage area where you can work on the parts in a release without affecting the ²official² versions of those parts. A work area can be associated with a speci®c defect or feature, but it does not have to be. These attributes can affect the state of a workarea:

track®xhold	With the track®xhold attribute and the ®x subprocess, a workarea will
	remain in the ®x state rather than moving to the integrate state when the
	®nalfix -complete command has been issued. A workarea -integrate
	command must be issued to move the workarea into the integrate state.
trackcommithold	If an environment list exists for the release associated with the work areas,
	the automatic transition to the test state can be disabled by including the
	-trackcommitholdattribute in the release process. A workarea -test
	command must be issued to move the workarea into the test state.
tracktesthold	With the tracktesthold attribute and the test subprocess, a workarea will
	remain in the test state rather than moving to the complete state when the
	®nal test is marked. Aworkarea -completecommand must be issued to
	move the workarea into the complete state.

Approve state

When a work area is created, it goes to this state if the release includes the approval subprocess. TeamConnection creates an approval record for each user on the release's approver list. Each approver indicates their evaluation of the changes in their approval record:

vAccept that work should continue

vAbstain if unable to assess if work should continue

vReject if work should not continue

When all approval records are marked as abstain or accept, the work area goes automatically to the ®x state. If any approval record is marked as reject, the state of the work area remains at approve. You can change rejected approval records to accept or abstain.

Fix state

If the release does not include the approval subprocess, work areas for the release begin in the ®x state.

While the work area is in this state, parts are checked out to the work area, changes are made to these parts, and builds are done to verify the accuracy of the changes.

If the release includes the ®x subprocess, any ®x records created for a defect or feature move to the active state when a part change is associated with the work area for the defect or feature. A ®x record monitors the part changes within a single component. Fix records provide a mechanism for reviewing all part changes that apply to components before integrating those changes with changes made for other defects and features.

Chapter 4. The states of TeamConnection objects 45