From:	STAR::S_SOMMER "Sue Sommer ZKO3-4/U14 381-0316  26-Oct-1995 0724" 26-OCT-1995 07:25:40.81
To:	@DISTLIST:OPENVMS_BASE_IO_SCSI
CC:	
Subj:	Guidelines for CLD checkins to SCSI

Guidelines for CLD checkins and propagations:

I volunteered to come up with a list of guidelines so that both the SCSI
team and sustaining engineering would have a reference for "who owns what"
in the area of CLD fixes.  So here they are;  in some cases it will probably
turn out to be more efficient or appropriate to modify these to fit the
particular situation.  But at least it gives us some common ground to start on.

1.  Keep in mind that the current (Oct 1995) Alpha propagation list looks 
    like this:

	V6.2R            V6.2
	  |                |
	  |                |
	  v                v
	Ghost           Theta-SSB
	  |                |
	  |                |
	  v                v
	Zombie -------> Gryphon-FT1

2.  In general sustaining engineering should own all checkins to
    V6.1R/V6.2R/Ghost/Zombie.  The OpenVMS SCSI team should own all checkins
    to Theta-SSB and Gryphon-FT*.  Note that Zombie checkins may result in
    a fold record to Gryphon;  the answer to "Should a fold record be created?"
    in this case should be No, so that OpenVMS and sustaining engineering won't
    have to wait on each other's checkins.  The two vertical streams above
    can stay independent (as they should be, since all the SCSI drivers 
    diverged as of 64-bit support in Theta).

    For VAX, same guidelines:  sustaining engineering should own the remedial
    streams, and OpenVMS SCSI should own Eagle/Gryphon.

3.  If an OpenVMS SCSI team member fixes a CLD, the source should be sent
    to sustaining engineering, who will create a test image and
    send it to the customer.  Meanwhile a code review should be done by
    at least one other SCSI team member.  Approval (via mail) should also
    be obtained from Glenn Everhart.  After the customer confirms the
    fix, sustaining engineering will check the source into the appropriate
    remedial stream.  If other remedial streams also need the fix, sustaining
    engineering should make those source changes and checkins.  The OpenVMS
    SCSI team member should do the source changes and checkins to Gryphon
    and possibly to Eagle or Theta (more on Eagle/Theta below).  The template 
    for Theta changes looks like this example:

$!	Project:		SCSI
$!	Project Leader:		Glenn Everhart (SCSI)
$!      Development Stream:	Theta-SSB
$!      Checkin Type:           BugFix
$!	Problem Symptom:        A zero byte count is returned in the IOSB
$!				whenever the user calls IO$_DIAGNOSE without
$!                              a user-supplied autosense buffer.
$!
$!	Diagnosis:	  	In the system-supplied autosense buffer path
$!	                        in the routine dkmk$diagnose_fdt, the return
$!				count variable was mistakenly calculated using
$!				a logical-or instead of a bit-or in C.
$!
$!	Cure:			Set the return count correctly using a bit-or
$!				instead of a logical-or.
$!					  
$!	Platforms affected:	Alpha only.
$!	  
$!	Modules:		[SCSI]DKMK.C
$!	  
$!	Affected Images (if feasible):  [SCSI]SYS$GKDRIVER.EXE
$!	                                [SCSI]SYS$DKDRIVER.EXE
$!					[SCSI]SYS$MKDRIVER.EXE
$!	Impact/Risks: 		Low.
$!	  
$!	Associated QARs,CLDs,SPRs: CLD #cfs.32321
$!	  
$!	(Optional) Comments:	Reviewed by Sue Sommer, Rick Lord.
$!				Tested by Sue Sommer.
$!	  
$!	(Optional) Special Build Instructions: 

4.  If sustaining engineering fixes a CLD, they will create a test image and
    send it to the customer.  Meanwhile a code review should be done by
    at least one other SCSI team member.  Approval (via mail) should also
    be obtained from Glenn Everhart.  After the customer confirms the
    fix, sustaining engineering will check the source into the appropriate
    remedial stream.  If other remedial streams also need the fix, sustaining
    engineering should make those source changes and checkins.  Sustaining
    engineering should then send the source to Sue Sommer, who will insure
    that someone from the SCSI team does sources changes and checkins for
    Theta/Eagle/Gryphon.

5.  About code reviews:  If there are fewer than about ten lines of obvious
    code involved, then review via mail seems adequate;  more than that,
    though, should call for 2 or 3 people in a conference room.  If the change
    is quite significant, formal inspection should be considered.

6.  About Theta:  Anything checked into Theta-SSB will not get field tested.
    The Theta release team is accepting high priority QAR fixes (and CLD
    fixes) through Friday, Oct 27.  We should probably be cautious about
    checkins, unless they are truly low risk;  talk to Glenn on this one,
    and just go on a case-by-case basis.  Also, Eagle has the same dates and
    restrictions as Theta.  For those fixes which are determined to be too
    high-risk for Theta/Eagle, the developer involved should be responsible
    for making the checkin to a V7.0 remedial stream as soon as that stream 
    opens.