X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C7B51E.8B144FC6@onstor-exch02.onstor.net>; Fri, 22 Jun 2007 14:41:59 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C7B51E.8B144FC6"
References: <BB375AF679D4A34E9CA8DFA650E2B04E0221588B@onstor-exch02.onstor.net>
Content-class: urn:content-classes:message
Subject: RE:  Branch Strategy
Date: Fri, 22 Jun 2007 14:39:50 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E02F3D335@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic:  Branch Strategy
Thread-Index: Ace0flY1X2fnXdFOQXyt1SzziCpH/wAdrLKQAApNVBk=
From: "Ken Renshaw" <ken.renshaw@onstor.com>
To: "Larry Scheer" <larry.scheer@onstor.com>,
	"Jay Michlin" <jay.michlin@onstor.com>,
	"Tim Gardner" <tim.gardner@onstor.com>
Cc: "Andy Sharp" <andy.sharp@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7B51E.8B144FC6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks for putting this together Larry, it looks like you captured all =
the details we went over. Good job.

-Ken


-----Original Message-----
From: Larry Scheer
Sent: Fri 6/22/2007 3:34 PM
To: Jay Michlin; Tim Gardner
Cc: Andy Sharp; Ken Renshaw; 'Larry Scheer'
Subject:  Branch Strategy
=20
Here is the Branch plan you asked for earlier this week. I met with Ken =
a couple of times to go over the gritty details.=20

Please review and give me any thoughts and changes. I am working on =
putting this into a functional specification. This email was =
easier/faster for me to create than working with MS-Word through Citrix.

Thanks,

Larry

 ONStor Branch Plan
This is a plan to implement a simpler more efficient branching strategy =
at ONStor. This plan will provide a common work flow for the software =
engineering process at ONStor. It will eliminate the indirect merges =
that we have had to deal with in the past. It provides a code base with =
common ancestry that is easy to follow and understand.=20

Branch types and their function
*	Main
=AD	Only one exists; the unique branch name is "main"
=AD	Provide stable revisions, points in time, to create a branch and to =
synchronize other branches
=AD	Provides the baseline history for all files and projects
=AD	Used as the genesis for all new feature branches and release =
branches
=AD	Used as the synchronization point for other branches as needed
=AD	Never ending branch

*	Dev
=AD	Only one exists; the unique name branch name is "dev"
=AD	A branch that contains all software projects and features targeted =
for a release
=AD	All software development work for projects not needing a feature =
branch done here
=AD	All bug fixes, with a few unique exceptions, done here
=AD	Projects are integrated here
=AD	Never ending branch

*	Bridge=20
=AD	Created as needed from a QA sanctioned submittal that was merged =
into main from the dev branch
=AD	Created from main the branch name matches the project (i. e. Zonda)
=AD	Removes the need to ever lock the dev branch and stall current =
development
=AD	Created just prior to a project's release, this branch will allow =
work on to continue on the dev branch
=AD	QA and bug fixes continue on the bridge until project is declared =
ready to release
=AD	When the code is release worthy it is pushed to the main branch
=AD	A release branch is created from the main branch at this time
=AD	At the same point the release is pulled from main into the dev =
branch
=AD	Short lived branch, with a life span of a handful of submittals to =
QA.

*	Release
=AD	Many can exist; the name of the branch will reflect the release =
number
=AD	Area that holds software released to manufacturing
=AD	Source for patch and maintenance releases as well as main release
=AD	Branched from main
=AD	Updated with fixes from the dev branch
=AD	In some cases fixes can be made directly in the release branch
=AD	Provides the stable point for "one-off" branches
=AD	Branch ends when no more maintenance is needed

*	One-Off
=AD	Many can exist; name of branch reflects patch number
=AD	Branched from the parent release branch
=AD	Modifications to code made directly in the branch
=AD	Holds unique special case software for one or few customers=20
=AD	Not generally available to a broad audience
=AD	Short lived branch

*	Feature Branch
=AD	Many can exist, name of branch reflects project name
=AD	Branched from main only on an as needed basis
=AD	Isolate development or whenever it is uncertain when the feature =
will be incorporated into a release
=AD	Updated from main=20
=AD	No indirect integrations are allowed in a feature branch
=AD	Pushed back into main before being pulled into dev
=AD	Has an end of life when feature is pushed into main and pulled into =
dev

Branch Policies

Main branch policy
*	Branch manager is Source Code Manager, Ken Renshaw
*	Holds tested code, "pushes" into main come from some checkpoint such =
as a submittal
*	Source for nearly all branches (only one-offs and maybe bridge the =
exception?)
*	No development done in main
*	Code that doesn't compile is never checked into main
*	No zero diffs checked into main?
*	Labels applied to help with identifying key events?

Dev branch policy
*	Development and bug fixing done here
*	Branch manager is the development release coordinator and will change =
from time to time
*	No pulls from other branches
*	No indirect merges
*	No checking in zero diffs
*	Pulls/synchronization from other branches, all integrations come =
through main

Bridge branch policy
*	Short life span
*	Branch manager is the development release coordinator
*	Branched sometime after feature complete (not too soon)
*	Tightly controlled updates to code
*	Locked when finished; becomes a dead branch
*	Merged back into main only
*	Dev branch is updated with this release through main

Release branch policy
*	Branch manager is Maintenance/Escalation manager (Ed Kwan)
*	Branched from main
*	All components needed for a build are branched (i. e. boot-tools, =
openbsd, linux, nfx-tree, etc)
*	Developers can build releases to verify fix if needed
*	Fixes come from the dev branch via integration and merge done by the =
developer
*	Fixes may be done directly in the release branch in cases where =
code/feature are incompatible with the dev branch. Example: send-agile =
replaced with rmc in dev and a fix is needed for send-agile in release
*	Code is never pushed back to main or dev
*	Release branch is always locked and opened only for specific fixes

One-Off branch policy
*	Branch manager is Maintenance/Escalation manager (Ed Kwan)
*	Branched from release branch
*	Developers can modify code and build a release to test (create fixes) =
as needed
*	Only done for specific reasons and customers
*	Fixes made directly in one-off branch
*	Never pulled from main, dev, etc. Never pushed to main, dev, etc.
*	Can be pushed back to release branch if needed
*	Branch is locked after fix=20
*	Very short lived branch

Feature branch policy
*	Branch manager is team leader, project manager, developer as needed
*	Always branched from main
*	Always pushed to main
*	Updated from main as needed
*	Developers responsible for integrations and merge
*	Must be updated from main and tested before pushed back into main
*	Feature branch is at end of life and locked when integrated into dev =
from main

How do we get there from here?
Today we have the main branch, a number of feature branches, a zonda =
branch for the 3.1 release work, a cougar branch for the linux port and =
new hardware support, and several active release branches where =
maintenance and new development are occurring. This section out lines =
the steps we will take to get engineering using the branch model =
proposed in this document.

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.

From this point on all development for releases and release maintenance =
will take place in the dev branch.

Work Flows
Each branch will have a branch manager. The branch manager is the =
gate-keeper for what goes into and out of a branch.  Depending on the =
branch the branch manager may change over time depending upon project =
and release status or as the needs of the company change.

Each branch will also have an integration/merge manager whose job it =
will be to integrate and merge changes into the branch using the =
perforce tools provided for the job. With the exception of the main and =
possibly bridge branches the integration/merge manager will not always =
be the same person for a given branch depending upon the need.

Main branch work flow
This branch is reserved for code that has passed some check-point and is =
used as a stable place for branch creation and to store a stable =
baseline of ONStor software. No development work occurs in the branch. =
Its purpose is to provide a common base for new projects and branches =
for those projects. Using main in this manner should allow all code to =
have a common ancestry and when used properly eliminates indirect =
merges. The branch manager is the release manager, Ken Renshaw. He will =
be responsible for controlling what goes into and out of the main =
branch. The release manager will also be the integration manager for the =
main branch.

Dev branch work flow
This is the primary branch for all development work and fixes to current =
releases. Normal development and code builds are done here at will by =
all software engineers. The branch manager will be the project leader =
for the current ONStor software release that is under development. The =
integration/merge manager will be appointed by the development team and =
they will pull from main any features and changes that need to come into =
the primary code line.

The escalation and maintenance team will also use the dev branch to fix =
defects and integrate fixes into the release branches whenever they can. =
This way fixes will be done to the current code base and patched in the =
release branch.

Bridge branch work flow
This branch will be created late in the development cycle of a project =
or a release by the release manager from the main branch after the dev =
branch has been pushed to main. Typically this would be done when the =
code base is nearing FCS and only has a few more weeks of code fixing =
and release candidate submittals left. The main purpose of this bridge =
branch is to allow work in the dev branch to continue unimpeded. This =
eliminates the need to lock the dev branch while a release is eminent.

Fixes will be done directly in the bridge branch by the developers. The =
project leader controls what goes into the branch and is the branch =
manager. The release manager, Ken Renshaw, will be the integration/merge =
manager. Release builds will be done as needed by developers and the =
release manager in this branch.

When the release is complete the bridge branch is pushed to main and the =
release branch is created from main at that point. From the same point =
in main the dev branch is updated with the released code base. The dev =
branch integration manager will pull the code base from main and merge =
it into dev.

Release branch work flow
The release branch is created from main at the point the bridge branch =
was integrated into the main branch. The release manager will create the =
release branch. In this branch post-release activity needed to create a =
patch releases or a maintenance release will come from the release =
branch. The escalation and maintenance team manager will manage this =
branch after its creation.

Whenever possible fixes will be made in the development branch and =
integrated from dev into the release branch by the developer. Here the =
integration/merge manager will be the developer responsible for the =
fix/change. The only time any direct changes, something other than =
merges, are acceptable on this branch is when the code being changed is =
incompatible with what is currently in the dev branch and the code being =
changed cannot be merged back to the dev branch.

Integrating code back into the main and dev branches from the release =
branch should be avoided. This practice could cause base line confusion =
and result in indirect integrations.

Developers creating fixes also will need to create test release builds =
in this branch. The release manager will be the primary person creating =
release builds for this branch.

One-Off branch work flow
These branches will be created as needed by the release manager. They =
will only be needed for work that is an engineering special project or =
is an unique feature or fix for one or few customers. The escalation and =
maintenance team manager will manage this branch after its creation.=20

Fixes and changes will be made directly in this branch and can be pushed =
back to the release branch if the changes are to become part of a patch =
or maintenance release. The integration/merge manager is the developer =
doing the work or the release manager.

Feature branch work flow
New feature branches are created when the work being done is outside the =
primary development stream or when the work to be done would be =
disruptive to the development code base. Any time work needs isolation =
from the primary development flow a feature branch is used. The branch =
manager will be the developer or team leader for the feature under =
development. The integration/merge manager will be appointed by the =
team.

Development work occurs in the feature branches in the usual manner with =
changes and builds being done by developers as needed. If a feature =
branch requires updates from a particular release, those updates will =
come from the main branch.

As feature branches are ready to be brought in to dev they will be =
synchronized with the main branch. The appointed branch merge manger =
will do the integration and merge of main into the feature branch. QA =
will perform an "in-branch" test of the code-line and when it is ready =
the feature branch will be pushed to main.

If for whatever reason QA cannot do an "in-branch" test before the =
branch is pushed to main all code must compile in the merged version and =
must pass some basic tests.

When a feature branch comes into main and the project manager wants to =
put the feature into his release the feature will be pulled into dev by =
the "merge manager" of the current release project.




------_=_NextPart_001_01C7B51E.8B144FC6
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>RE:  Branch Strategy</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Thanks for putting this together Larry, it looks like =
you captured all the details we went over. Good job.<BR>
<BR>
-Ken<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Larry Scheer<BR>
Sent: Fri 6/22/2007 3:34 PM<BR>
To: Jay Michlin; Tim Gardner<BR>
Cc: Andy Sharp; Ken Renshaw; 'Larry Scheer'<BR>
Subject:&nbsp; Branch Strategy<BR>
<BR>
Here is the Branch plan you asked for earlier this week. I met with Ken =
a couple of times to go over the gritty details.<BR>
<BR>
Please review and give me any thoughts and changes. I am working on =
putting this into a functional specification. This email was =
easier/faster for me to create than working with MS-Word through =
Citrix.<BR>
<BR>
Thanks,<BR>
<BR>
Larry<BR>
<BR>
&nbsp;ONStor Branch Plan<BR>
This is a plan to implement a simpler more efficient branching strategy =
at ONStor. This plan will provide a common work flow for the software =
engineering process at ONStor. It will eliminate the indirect merges =
that we have had to deal with in the past. It provides a code base with =
common ancestry that is easy to follow and understand.<BR>
<BR>
Branch types and their function<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Main<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Only one exists; the unique =
branch name is &quot;main&quot;<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Provide stable revisions, points =
in time, to create a branch and to synchronize other branches<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Provides the baseline history =
for all files and projects<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Used as the genesis for all new =
feature branches and release branches<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Used as the synchronization =
point for other branches as needed<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Never ending branch<BR>
<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dev<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Only one exists; the unique name =
branch name is &quot;dev&quot;<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A branch that contains all =
software projects and features targeted for a release<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; All software development work =
for projects not needing a feature branch done here<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; All bug fixes, with a few unique =
exceptions, done here<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Projects are integrated here<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Never ending branch<BR>
<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bridge<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Created as needed from a QA =
sanctioned submittal that was merged into main from the dev branch<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Created from main the branch =
name matches the project (i. e. Zonda)<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Removes the need to ever lock =
the dev branch and stall current development<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Created just prior to a =
project's release, this branch will allow work on to continue on the dev =
branch<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; QA and bug fixes continue on the =
bridge until project is declared ready to release<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When the code is release worthy =
it is pushed to the main branch<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A release branch is created from =
the main branch at this time<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; At the same point the release is =
pulled from main into the dev branch<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Short lived branch, with a life =
span of a handful of submittals to QA.<BR>
<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Release<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Many can exist; the name of the =
branch will reflect the release number<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Area that holds software =
released to manufacturing<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Source for patch and maintenance =
releases as well as main release<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branched from main<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Updated with fixes from the dev =
branch<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In some cases fixes can be made =
directly in the release branch<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Provides the stable point for =
&quot;one-off&quot; branches<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branch ends when no more =
maintenance is needed<BR>
<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; One-Off<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Many can exist; name of branch =
reflects patch number<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branched from the parent release =
branch<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Modifications to code made =
directly in the branch<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Holds unique special case =
software for one or few customers<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Not generally available to a =
broad audience<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Short lived branch<BR>
<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Feature Branch<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Many can exist, name of branch =
reflects project name<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branched from main only on an as =
needed basis<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Isolate development or whenever =
it is uncertain when the feature will be incorporated into a release<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Updated from main<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No indirect integrations are =
allowed in a feature branch<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pushed back into main before =
being pulled into dev<BR>
=AD&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Has an end of life when feature =
is pushed into main and pulled into dev<BR>
<BR>
Branch Policies<BR>
<BR>
Main branch policy<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branch manager is Source Code =
Manager, Ken Renshaw<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Holds tested code, =
&quot;pushes&quot; into main come from some checkpoint such as a =
submittal<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Source for nearly all branches =
(only one-offs and maybe bridge the exception?)<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No development done in main<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Code that doesn't compile is never =
checked into main<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No zero diffs checked into =
main?<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Labels applied to help with =
identifying key events?<BR>
<BR>
Dev branch policy<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Development and bug fixing done =
here<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branch manager is the development =
release coordinator and will change from time to time<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No pulls from other branches<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No indirect merges<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No checking in zero diffs<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pulls/synchronization from other =
branches, all integrations come through main<BR>
<BR>
Bridge branch policy<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Short life span<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branch manager is the development =
release coordinator<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branched sometime after feature =
complete (not too soon)<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tightly controlled updates to =
code<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Locked when finished; becomes a =
dead branch<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Merged back into main only<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Dev branch is updated with this =
release through main<BR>
<BR>
Release branch policy<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branch manager is =
Maintenance/Escalation manager (Ed Kwan)<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branched from main<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; All components needed for a build =
are branched (i. e. boot-tools, openbsd, linux, nfx-tree, etc)<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Developers can build releases to =
verify fix if needed<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fixes come from the dev branch via =
integration and merge done by the developer<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fixes may be done directly in the =
release branch in cases where code/feature are incompatible with the dev =
branch. Example: send-agile replaced with rmc in dev and a fix is needed =
for send-agile in release<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Code is never pushed back to main =
or dev<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Release branch is always locked =
and opened only for specific fixes<BR>
<BR>
One-Off branch policy<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branch manager is =
Maintenance/Escalation manager (Ed Kwan)<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branched from release branch<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Developers can modify code and =
build a release to test (create fixes) as needed<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Only done for specific reasons and =
customers<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fixes made directly in one-off =
branch<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Never pulled from main, dev, etc. =
Never pushed to main, dev, etc.<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Can be pushed back to release =
branch if needed<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branch is locked after fix<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Very short lived branch<BR>
<BR>
Feature branch policy<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Branch manager is team leader, =
project manager, developer as needed<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Always branched from main<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Always pushed to main<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Updated from main as needed<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Developers responsible for =
integrations and merge<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Must be updated from main and =
tested before pushed back into main<BR>
*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Feature branch is at end of life =
and locked when integrated into dev from main<BR>
<BR>
How do we get there from here?<BR>
Today we have the main branch, a number of feature branches, a zonda =
branch for the 3.1 release work, a cougar branch for the linux port and =
new hardware support, and several active release branches where =
maintenance and new development are occurring. This section out lines =
the steps we will take to get engineering using the branch model =
proposed in this document.<BR>
<BR>
1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The current &quot;pre 3.0 release&quot; =
branches remain as they are nothing additional needs to be done =
there<BR>
2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The main branch will be updated one =
last time with the current release from the FB-DELOREAN branch<BR>
3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FB- DELOREAN will be locked and is =
done.<BR>
4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; R3_0_X_rel branch will be updated from =
main with the FB- DELOREAN code<BR>
5.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The ZONDA branch will be update from =
main with the FB- DELOREAN code<BR>
6.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ZONDA submittal one will be tested by =
QA,<BR>
7.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If all goes well the ZONDA branch will =
be pushed to main<BR>
8.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The ZONDA branch will be locked and it =
is at end&nbsp; of life<BR>
9.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The cougar branch will be updated with =
the ZONDA + final FB- DELOREAN release from the main branch<BR>
10.&nbsp;&nbsp;&nbsp;&nbsp; Any needed ZONDA development (expected to be =
brief) will/can happen in the cougar branch<BR>
11.&nbsp;&nbsp;&nbsp;&nbsp; ZONDA submittal 2 will come out of the =
cougar branch<BR>
12.&nbsp;&nbsp;&nbsp;&nbsp; If all goes well the cougar branch will be =
pushed to main<BR>
13.&nbsp;&nbsp;&nbsp;&nbsp; The cougar branch is at its end of life and =
it is locked<BR>
14.&nbsp;&nbsp;&nbsp;&nbsp; The dev branch is created from main<BR>
15.&nbsp;&nbsp;&nbsp;&nbsp; All future zonda submittals come from the =
dev branch until the zonda bridge branch is needed.<BR>
<BR>
From this point on all development for releases and release maintenance =
will take place in the dev branch.<BR>
<BR>
Work Flows<BR>
Each branch will have a branch manager. The branch manager is the =
gate-keeper for what goes into and out of a branch.&nbsp; Depending on =
the branch the branch manager may change over time depending upon =
project and release status or as the needs of the company change.<BR>
<BR>
Each branch will also have an integration/merge manager whose job it =
will be to integrate and merge changes into the branch using the =
perforce tools provided for the job. With the exception of the main and =
possibly bridge branches the integration/merge manager will not always =
be the same person for a given branch depending upon the need.<BR>
<BR>
Main branch work flow<BR>
This branch is reserved for code that has passed some check-point and is =
used as a stable place for branch creation and to store a stable =
baseline of ONStor software. No development work occurs in the branch. =
Its purpose is to provide a common base for new projects and branches =
for those projects. Using main in this manner should allow all code to =
have a common ancestry and when used properly eliminates indirect =
merges. The branch manager is the release manager, Ken Renshaw. He will =
be responsible for controlling what goes into and out of the main =
branch. The release manager will also be the integration manager for the =
main branch.<BR>
<BR>
Dev branch work flow<BR>
This is the primary branch for all development work and fixes to current =
releases. Normal development and code builds are done here at will by =
all software engineers. The branch manager will be the project leader =
for the current ONStor software release that is under development. The =
integration/merge manager will be appointed by the development team and =
they will pull from main any features and changes that need to come into =
the primary code line.<BR>
<BR>
The escalation and maintenance team will also use the dev branch to fix =
defects and integrate fixes into the release branches whenever they can. =
This way fixes will be done to the current code base and patched in the =
release branch.<BR>
<BR>
Bridge branch work flow<BR>
This branch will be created late in the development cycle of a project =
or a release by the release manager from the main branch after the dev =
branch has been pushed to main. Typically this would be done when the =
code base is nearing FCS and only has a few more weeks of code fixing =
and release candidate submittals left. The main purpose of this bridge =
branch is to allow work in the dev branch to continue unimpeded. This =
eliminates the need to lock the dev branch while a release is =
eminent.<BR>
<BR>
Fixes will be done directly in the bridge branch by the developers. The =
project leader controls what goes into the branch and is the branch =
manager. The release manager, Ken Renshaw, will be the integration/merge =
manager. Release builds will be done as needed by developers and the =
release manager in this branch.<BR>
<BR>
When the release is complete the bridge branch is pushed to main and the =
release branch is created from main at that point. From the same point =
in main the dev branch is updated with the released code base. The dev =
branch integration manager will pull the code base from main and merge =
it into dev.<BR>
<BR>
Release branch work flow<BR>
The release branch is created from main at the point the bridge branch =
was integrated into the main branch. The release manager will create the =
release branch. In this branch post-release activity needed to create a =
patch releases or a maintenance release will come from the release =
branch. The escalation and maintenance team manager will manage this =
branch after its creation.<BR>
<BR>
Whenever possible fixes will be made in the development branch and =
integrated from dev into the release branch by the developer. Here the =
integration/merge manager will be the developer responsible for the =
fix/change. The only time any direct changes, something other than =
merges, are acceptable on this branch is when the code being changed is =
incompatible with what is currently in the dev branch and the code being =
changed cannot be merged back to the dev branch.<BR>
<BR>
Integrating code back into the main and dev branches from the release =
branch should be avoided. This practice could cause base line confusion =
and result in indirect integrations.<BR>
<BR>
Developers creating fixes also will need to create test release builds =
in this branch. The release manager will be the primary person creating =
release builds for this branch.<BR>
<BR>
One-Off branch work flow<BR>
These branches will be created as needed by the release manager. They =
will only be needed for work that is an engineering special project or =
is an unique feature or fix for one or few customers. The escalation and =
maintenance team manager will manage this branch after its creation.<BR>
<BR>
Fixes and changes will be made directly in this branch and can be pushed =
back to the release branch if the changes are to become part of a patch =
or maintenance release. The integration/merge manager is the developer =
doing the work or the release manager.<BR>
<BR>
Feature branch work flow<BR>
New feature branches are created when the work being done is outside the =
primary development stream or when the work to be done would be =
disruptive to the development code base. Any time work needs isolation =
from the primary development flow a feature branch is used. The branch =
manager will be the developer or team leader for the feature under =
development. The integration/merge manager will be appointed by the =
team.<BR>
<BR>
Development work occurs in the feature branches in the usual manner with =
changes and builds being done by developers as needed. If a feature =
branch requires updates from a particular release, those updates will =
come from the main branch.<BR>
<BR>
As feature branches are ready to be brought in to dev they will be =
synchronized with the main branch. The appointed branch merge manger =
will do the integration and merge of main into the feature branch. QA =
will perform an &quot;in-branch&quot; test of the code-line and when it =
is ready the feature branch will be pushed to main.<BR>
<BR>
If for whatever reason QA cannot do an &quot;in-branch&quot; test before =
the branch is pushed to main all code must compile in the merged version =
and must pass some basic tests.<BR>
<BR>
When a feature branch comes into main and the project manager wants to =
put the feature into his release the feature will be pulled into dev by =
the &quot;merge manager&quot; of the current release project.<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C7B51E.8B144FC6--
