X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C7BF49.AA3531CF@onstor-exch02.onstor.net>; Thu, 5 Jul 2007 13:15:51 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: Zonda submittals and the cut-over to dev
Date: Thu, 5 Jul 2007 13:15:51 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E046A84F9@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E02EB2F2A@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Zonda submittals and the cut-over to dev
Thread-Index: Ace/R6Of8qLtHLxxRqGyWBswJckwJQAAPKZtAAAqV8A=
References: <BB375AF679D4A34E9CA8DFA650E2B04E02EB2F2A@onstor-exch02.onstor.net>
From: "Brian DeForest" <brian.deforest@onstor.com>
To: "Ken Renshaw" <ken.renshaw@onstor.com>,
	"Larry Scheer" <larry.scheer@onstor.com>
Cc: "Andy Sharp" <andy.sharp@onstor.com>

Guys, we're still waiting for test results for both Zonda sub2 and
Cougar BSD builds.  I would think we'll have both this week.

-----Original Message-----
From: Ken Renshaw=20
Sent: Thursday, July 05, 2007 2:08 PM
To: Larry Scheer
Cc: Andy Sharp; Brian DeForest
Subject: Re: Zonda submittals and the cut-over to dev

Thanks Larry, and yes I agree with your logic/statements. To my mind the
next thing to happen to trigger this all should be Brian OKing the
locking and cutover of zonda. As soon as he gives the sign I'll
immediately lock zonda, make sure what's in it builds, then push to main
for cougar consumption.

-Ken


=20

-----Original Message-----
From: Larry Scheer
To: Ken Renshaw
CC: Andy Sharp; Brian DeForest
Sent: Thu Jul 05 14:01:20 2007
Subject: Zonda submittals and the cut-over to dev

Ken,
   We talked about cutting over to the dev branch ASAP and of the steps
below, 1 through 6 are complete. Some things have happened that are not
precisely in the order given below, such as:=20
-	The cougar branch has been updated with main that contains the
final check-ins from Delorean.
-	Zonda submittal one did not contain the final Delorean
check-ins, those are in submittal two
-	Zonda submittal two is in QA and came from the Zonda branch

These divergences from the steps we talked about are no big deal and
make the process a bit more organic. What remains are the critical
pieces that need to be managed carefully.  I think step 8 locking the
Zonda branch needs to happen before step 7, pushing Zonda to main.=20

Since submittal two we already have had some check-ins to the Zonda
branch. Perhaps the Zonda branch needs to be locked now. Either that or
there must be an agreement to pull into main these latest untested
check-ins.
Those changes will be propagated to the cougar branch when it is synched
from main. Next Zonda submittal 3 comes from the cougar branch.=20

Does this sound like a reasonable plan and when do you think the Zonda
branch can be locked?

The original steps to cut over to the development branch:

1.	The current "pre 3.0 release" branches remain as they are
nothing additional needs to be done there
2.	The main branch will be updated one last time with the current
release from the FB-DELOREAN branch
3.	FB- DELOREAN will be locked and is done.
4.	R3_0_X_rel branch will be updated from main with the FB-
DELOREAN code
5.	The ZONDA branch will be update from main with the FB- DELOREAN
code
6.	ZONDA submittal one will be tested by QA,
7.	If all goes well the ZONDA branch will be pushed to main
8.	The ZONDA branch will be locked and it is at end of life
9.	The cougar branch will be updated with the ZONDA + final FB-
DELOREAN release from the main branch
10.	Any needed ZONDA development (expected to be brief) will/can
happen in the cougar branch
11.	ZONDA submittal 2 will come out of the cougar branch
12.	If all goes well the cougar branch will be pushed to main
13.	The cougar branch is at its end of life and it is locked
14.	The dev branch is created from main
15.	All future zonda submittals come from the dev branch until the
zonda bridge branch is needed.

Here are the remaining steps as I see them. Let me know if there are any
changes you recommend. Jay wants me to publish an email to dl-eng
outlining the remaining steps ASAP.

1.	Get developers to submit any outstanding Zonda change lists
2.	Lock the ZONDA branch (it is now dead)
3.	Integrate latest in ZONDA to main
4.	Integrate cougar with latest in main
5.	Developers submit all outstanding work/changes for the cougar
branch
6.	Fix any last minute build issues, etc.
7.	Zonda submittal three comes from the cougar branch
8.	The cougar branch is locked and at end of life (avoid the
problem of check-ins after submittal)
9.	The cougar branch is pushed to main
10.	The dev branch is created from main
11.	All future Zonda submittals come from the dev branch until the
Zonda release branch is created.

Thanks,

Larry
