X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C79E5E.F0AEDDCF@onstor-exch02.onstor.net>; Thu, 24 May 2007 16:55:00 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C79E5E.F0AEDDCF"
Content-class: urn:content-classes:message
Subject: RE: Notes from branch strategy meeting 5/23/07 
Date: Thu, 24 May 2007 16:55:00 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E03D91690@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E022157ED@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Notes from branch strategy meeting 5/23/07 
Thread-Index: AcedmnqJbdDusNPISb6brV4R3x+UzQAxBugw
From: "Jay Michlin" <jay.michlin@onstor.com>
To: "Larry Scheer" <larry.scheer@onstor.com>,
	"Tim Gardner" <tim.gardner@onstor.com>,
	"Andy Sharp" <andy.sharp@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C79E5E.F0AEDDCF
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Larry,

Your writeup is superb, and goes well beyond aything I wrote on the
board. Many thanks.

I have not done anything on this issue today because I didn't have the
time. Besides, I've found that tough issues of this kind work out better
if I give them a little time to percolate. Though I know that makes your
lives more difficult, I'm hoping it will allow me to get this resolved
without interfering with your work further.

Right now, the responsibility is mine. I'll keep you posted.

jay

> _____________________________________________=20
> From: 	Larry Scheer =20
> Sent:	Wednesday, May 23, 2007 5:29 PM
> To:	Jay Michlin; Tim Gardner; Andy Sharp
> Cc:	Larry Scheer
> Subject:	Notes from branch strategy meeting 5/23/07=20
>=20
> The Branch Strategy under Fire =20
> The controversy is being created by Engineering's desire to push
> Cougar work into Zonda. This will happen either by working us directly
> out of main or pushing the cougar branch into main and then
> synchronizing the Zonda branch from main. The perception is that it is
> risky to proceed with this plan and management wants to minimize risk.
>=20
> To understand the big picture we need to review some things...
>=20
> Why Branch at all?
> *	Need to isolate development projects
> *	Provide stable area with low churn - I. E. QA test and Release
> to customers, Release patches, fixes.
> *	Want to moderate risk of one development project impacting
> another -This could be pure illusion.
>=20
> Problems with Current Branching Scheme
> *	Not all of product base is branched on a Release branch.
> (Example: only nfx-tree and not openbsd)=20
> *	No common genesis for source code
> *	No contiguous history for file
> *	To discover the history of a single file is an archaeological
> process=20
> *	Many branch to branch merges were done. Many indirect merges
> were done. Both of these create difficulty for merge tools to do
> automatic merges and many conflicts appear that need to be resolved.
> It also lost the common ancestor for individual files.
> *	Dozens (perhaps hundreds?) of branches
> *	Requires good understanding of all branches, their original
> history, and time of creation. Can you answer this question by looking
> at our branches; "What came first, Clio or Lynx?"
>=20
> Problems with Working in Multiple Branches
> *	Work happens in isolation
> *	No substitution for good engineering communications
> *	Problems created by parallel development are found later, by QA
> typically, rather than early in the development process.=20
> *	Development diverges; need to do the work all over again in
> another branch. Example: CLI-re-factoring coming into Cougar branch.
> *	Integration could become problematic if common ancestor for
> merge is lost/unknown was often the case here at ONStor because of
> past history.=20
> *	See Problems with Integration for more issues
>=20
> Problems with Integration (aka merge)
> *	Developers need good tools and know how to use them
> *	Takes extra time effort to do integration. - Not always as
> simple as p4 resolve -as; p4 resolve -am; unless you want to be a
> total cowboy and fix the botched automatic merge later.
> *	Need common code base with frequent synchronization to make
> automatic merges easier.
>=20
> Why Work out of Main or a Common Branch for Development?
> *	Find parallel development conflicts early when you want to find
> them and not later
> *	Leads to good engineering communications
> *	Integrations are infrequent
> *	Problems are found quicker by developers
> *	Features and changes are seen by all development
> *	With fewer than 50 developer (well maybe 25) need for isolation
> is not as critical
>=20
> Today's Branching Scheme -- One Removed from Working Directly Out of
> Main
> *	Cougar is branched from main and we pull from main latest
> features and releases pushed to it=20
> *	Hope to do the same with Zonda=20
> *	Code releases, fixes, and features are pushed to main when ready
> (passed some stability check point)
> *	All branches are one off of main with frequent pulls from main
> to synchronize the bracnches
> *	Branches push back into main when passed some stability check
> point so other branches can share features. (This item may be
> controversial but it is what we hope to see with cougar. We currently
> do it with Delorean to get the latest development into cougar.)
>=20
>=20
> The Cougar and Future Development Strategy
> *	Not just a branching structure that is involved
> *	Code restructuring=20
> *	Hardening of the build system (today's build system is designed
> to handle multiple products)
> *	Complete design to handle building and developing for any
> arbitrary platform
> *	Designed so no cougar code will be built in a non-cougar
> platform
> *	Designed so no Linux code will be built into a BSD platform
>=20
> Benefits
> *	We will not need to do the work all over again once Zonda is
> released
> *	Problems created by parallel development are found early in the
> development process.=20
> *	Promotes good communication in engineering
>=20
> Risks
> *	None
> *	No more risky than any other code modification
>=20
> For more information on the code restructuring see the URL below:
> http://wiki.onstor.net/wiki/Cookbook:_Porting_Management_Daemons_and_A
> pplications
>=20
>=20
>=20

------_=_NextPart_001_01C79E5E.F0AEDDCF
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>RE: Notes from branch strategy meeting 5/23/07 </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Larry,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Your writeup is =
superb, and goes well beyond aything I wrote on the board. Many =
thanks.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I have not done =
anything on this issue today because I didn't have the time. Besides, =
I've found that tough issues of this kind work out better if I give them =
a little time to percolate. Though I know that makes your lives more =
difficult, I'm hoping it will allow me to get this resolved without =
interfering with your work further.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Right now, the =
responsibility is mine. I'll keep you posted.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">jay</FONT>
</P>

<P><FONT SIZE=3D1 =
FACE=3D"Tahoma">_____________________________________________ </FONT>

<BR><B><FONT SIZE=3D1 FACE=3D"Tahoma">From: &nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Tahoma">Larry Scheer&nbsp; </FONT>

<BR><B><FONT SIZE=3D1 FACE=3D"Tahoma">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Tahoma">Wednesday, May 23, 2007 5:29 PM</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">Jay Michlin; Tim Gardner; Andy Sharp</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">Larry Scheer</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Tahoma">Notes from branch strategy meeting =
5/23/07 </FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">The Branch Strategy under Fire&nbsp; =
</FONT></B>

<BR><FONT SIZE=3D2 FACE=3D"Arial">The controversy is being created by =
Engineering&#8217;s desire to push Cougar work into Zonda. This will =
happen either by working us directly out of main or pushing the cougar =
branch into main and then synchronizing the Zonda branch from main. The =
perception is that it is risky to proceed with this plan and management =
wants to minimize risk.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">To understand the big picture we need =
to review some things&#8230;</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Why Branch at all?</FONT></B>
<UL>
<UL>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Need to isolate development =
projects</FONT><B></B></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Provide stable area with low churn =
&#8211; I. E. QA test and Release to customers, Release patches, =
fixes.</FONT><B></B></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Want to moderate risk of one =
development project impacting another &#8211;This could be pure =
illusion.</FONT><B></B></LI>
<BR>
</UL></UL>
<P><B><FONT SIZE=3D2 FACE=3D"Arial">Problems with Current Branching =
Scheme</FONT></B>
<UL>
<UL>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Not all of product base is branched on =
a Release branch. (Example: only nfx-tree and not openbsd)</FONT><B> =
</B></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">No common genesis for source =
code</FONT><B></B></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">No contiguous history for =
file</FONT><B></B></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">To discover the history of a single =
file is an archaeological process</FONT><B> </B></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Many branch to branch merges were =
done</FONT><B><FONT SIZE=3D2 FACE=3D"Arial">.</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">Many indirect merges were done. Both of these create =
difficulty for merge tools to do automatic merges and many conflicts =
appear that need to be resolved. It also lost the common ancestor for =
individual files.</FONT><B></B></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Dozens (perhaps hundreds?) of =
branches</FONT><B></B></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Requires good understanding of all =
branches, their original history, and time of creation. Can you answer =
this question by looking at our branches; &#8220;What came first, Clio =
or Lynx?&#8221;</FONT><B></B></LI>
<BR>
</UL></UL>
<P><B><FONT SIZE=3D2 FACE=3D"Arial">Problems with Working in Multiple =
Branches</FONT></B>
<UL>
<UL>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Work happens in isolation</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">No substitution for good engineering =
communications</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Problems created by parallel =
development are found later, by QA typically, rather than early in the =
development process. </FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Development diverges; need to do the =
work all over again in another branch. Example: CLI-re-factoring coming =
into Cougar branch.</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Integration could become problematic =
if common ancestor for merge is lost/unknown was often the case here at =
ONStor because of past history. </FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">See Problems with Integration for more =
issues</FONT></LI>
<BR>
</UL></UL>
<P><B><FONT SIZE=3D2 FACE=3D"Arial">Problems with Integration (aka =
merge)</FONT></B>
<UL>
<UL>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Developers need good tools and know =
how to use them</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Takes extra time effort to do =
integration. &#8211; Not always as simple as p4 resolve &#8211;as; p4 =
resolve &#8211;am; unless you want to be a total cowboy and fix the =
botched automatic merge later.</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Need common code base with frequent =
synchronization to make automatic merges easier.</FONT></LI>
<BR>
</UL></UL>
<P><B><FONT SIZE=3D2 FACE=3D"Arial">Why Work out of Main or a Common =
Branch for Development?</FONT></B>
<UL>
<UL>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Find parallel development conflicts =
early when you want to find them and not later</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Leads to good engineering =
communications</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Integrations are =
infrequent</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Problems are found quicker by =
developers</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Features and changes are seen by all =
development</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">With fewer than 50 developer (well =
maybe 25) need for isolation is not as critical</FONT></LI>
<BR>
</UL></UL>
<P><B><FONT SIZE=3D2 FACE=3D"Arial">Today&#8217;s Branching Scheme -- =
One Removed from Working Directly Out of Main</FONT></B>
<UL>
<UL>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Cougar is branched from main and we =
pull from main latest features and releases pushed to it </FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Hope to do the same with Zonda =
</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Code releases, fixes, and features are =
pushed to main when ready (passed some stability check =
point)</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">All branches are one off of main with =
frequent pulls from main to synchronize the bracnches</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Branches push back into main when =
passed some stability check point so other branches can share features. =
(This item may be controversial but it is what we hope to see with =
cougar. We currently do it with Delorean to get the latest development =
into cougar.)</FONT></LI>
<BR>
<BR>
</UL></UL>
<P><B><FONT SIZE=3D2 FACE=3D"Arial">The Cougar and Future Development =
Strategy</FONT></B>
<UL>
<UL>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Not just a branching structure that is =
involved</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Code restructuring </FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Hardening of the build system =
(today&#8217;s build system is designed to handle multiple =
products)</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Complete design to handle building and =
developing for any arbitrary platform</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Designed so no cougar code will be =
built in a non-cougar platform</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Designed so no Linux code will be =
built into a BSD platform</FONT></LI>
<BR>
</UL></UL>
<P><B><FONT SIZE=3D2 FACE=3D"Arial">Benefits</FONT></B>
<UL>
<UL>
<LI><FONT SIZE=3D2 FACE=3D"Arial">We will not need to do the work all =
over again once Zonda is released</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Problems created by parallel =
development are found early in the development process. </FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">Promotes good communication in =
engineering</FONT></LI>
<BR>
</UL></UL>
<P><B><FONT SIZE=3D2 FACE=3D"Arial">Risks</FONT></B>
<UL>
<UL>
<LI><FONT SIZE=3D2 FACE=3D"Arial">None</FONT></LI>

<LI><FONT SIZE=3D2 FACE=3D"Arial">No more risky than any other code =
modification</FONT></LI>
<BR>
</UL></UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">For more information on the code =
restructuring see the URL below:</FONT>

<BR><A =
HREF=3D"http://wiki.onstor.net/wiki/Cookbook:_Porting_Management_Daemons_=
and_Applications"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://wiki.onstor.net/wiki/Cookbook:_Porting_Management_D=
aemons_and_Applications</FONT></U></A>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C79E5E.F0AEDDCF--
