X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C7B847.2DE741DE@onstor-exch02.onstor.net>; Tue, 26 Jun 2007 15:10:25 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: FW: Zonda submittal, volume testing, branching and related issues
Date: Tue, 26 Jun 2007 15:10:25 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E0451D5C4@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Zonda submittal, volume testing, branching and related issues
Thread-Index: Ace3gG8NMdfJNe1jSb+NsGTiEgZcIwAAtfMQADC6IoA=
From: "Tim Gardner" <tim.gardner@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>
Cc: "Jay Michlin" <jay.michlin@onstor.com>,
	"Brian DeForest" <brian.deforest@onstor.com>,
	"Larry Scheer" <larry.scheer@onstor.com>

Andy,

I am totally burned out on this branch strategy discussion.
At this point I don't care what we do. I am willing to let others
decide and suffer the consequences. I leave it up to you and Larry
to carry the torch until you guys also die of exhaustion. I need to get
some
real work done. I hereby officially delegate the handling of this issue
to=20
you. I don't ever want to hear the words "branch strategy" again.

Tim


-----Original Message-----
From: Brian DeForest=20
Sent: Tuesday, June 26, 2007 3:41 PM
To: Jay Michlin
Cc: Tim Gardner; Larry Scheer; Jerry Lopatin
Subject: RE: Zonda submittal, volume testing, branching and related
issues

My comments on the branch strategy plans.   I've removed QA/Build from
the CC list since we need to first get agreement within the Software
team before we propose anything to QA/Build. =20

3. Zonda/Cougar branch strategy=20

I think we need to keep in mind that the Delorean code base is currently
our most tested and stable code base to date, and that we need to build
upon and maintain a stable foundation going forward, and take controlled
risks where necessary.  We agreed in principle there are benefits to
collapsing the Zonda and Cougar branches at some point.  Tim and I have
an action item to determine when to do the merge.  I thought Tim and I
would be the owners of this decision, however apparently others have an
interest as well, so let me summarize my current thinking.

Building Zonda submittal 2 from the merged Zonda and Cougar branches (as
suggested in the wiki document) seems premature because the current BSD
build from the Cougar branch has not been in-branch tested by QA
(correct me if that's incorrect), as we typically do prior to merging
any feature branch into a more stable project branch in order to
maintain stability in the project branch.  As we discussed, we need to
assume there will be some degree of instability introduced into Zonda
when we merge Cougar code.  So, the challenge is to determine when to
take this risk.  At a minimum, for starters I think we need to
demonstrate that Zonda and the Bobcat BSD build from the Cougar branch
are functionally equivalent, as Tim and I have discussed.  One way to do
this is identical in-branch testing of both builds as a pre-requisite
for merging the two branches.  This would require QA assistance
presumably.  I'm open to other suggestions.

For the sake of comparison, in Delorean we merged multiple feature
branches (GNS, SNMP, Kerberos, performance) and each had significant
in-branch testing done prior to merging in order to determine "merge
readiness".  This allowed us (me) to maintain a relatively stable code
base while adding functionality at specific merge points.  The FB's with
relatively self-contained code (e.g. SNMP, Kerberos, and to some degree
GNS) merged smoothly with no major consequences.  The FB's with broader
changes resulted in regressions and had a greater destabilizing impact.
This is generally expected to some degree -- you take one step backwards
before 2 steps forwards.  The Cougar code changes are potentially broad
though not necessarily complex but do include changes to numerous
subsystems that could potentially impact overall system stability (worst
case).

We should also consider that the Cougar Linux port isn't completed.
Consequently if we were to merge today, there are still numerous
subsystems that remain to be ported, each of which could introduce
instability into the Zonda (or, common "dev") branch anytime in the
Zonda timeframe.  It is difficult to test many of the subsystems in
isolation prior to merging since there are multiple inter-dependencies
in our system. =20

Because it is difficult to test many of our subsystems independently, we
could consider completion of major Bobcat Linux milestones as potential
"merge points", including:
1.  basic functionality: NFS, CIFS, NIS, LDAP, DNS, DMIP, SSH,
clustering, ...
2.  #1 plus system management: NCM, SNMP, ...
3.  Bobcat Linux completed (#1 & #2)
To my knowledge milestone #1 hasn't been completed yet.  The schedules
for these milestones would need to also be aligned with the Zonda
schedule to determine which (if not all) will be completed prior to
Zonda being feature complete.  Perhaps Tim has target dates for these or
similar milestones. =20

An additional consideration is how much time we will actually benefit
from the common "dev" branch.  For example, let's suppose that Zonda
will be feature complete on 8/31, and a basic Bobcat Linux port is
completed 7/31 (milestone #1 above).  Note that these are both just
hypothetical, not actual, target dates.  On or around 8/31 we would need
to create a 3.1 branch to isolate the Zonda code, so as not to
destabilize the Zonda release with any Cougar checkins.  At this point
we're developing Zonda and Cougar in separate branches again.  So the
effective use of the common "dev" branch using the above hypothetical
dates would be 4 weeks (7/31 - 8/31).  I believe Ken made a similar
point in a meeting several weeks ago.

I should also mention that these are not exclusively my opinions but the
shared concerns of several Zonda senior developers who are also trying
to look out for the best interests of both the Zonda and Cougar
projects. =20

In summary, several Zonda developers and I are not necessarily
categorically opposed to merging the Zonda and Cougar code in the Zonda
timeframe, however we are concerned about potential risks if this merge
is done prematurely, and is not merged when determined to be "merge
ready" just like other feature branches.  Tim and I should agree upon
the target date and criteria for the merge.

And I'm definitely not trying to be anal about this or a pain-in-the-***
(contrary to what the reader might be thinking at this point), but my
motive is to make sure we meet our Zonda and Cougar quality and schedule
objectives by following methodical software development practices.  Put
another way, I want to make sure both projects succeed, since both are
critical to the company's success.

Brian

-----Original Message-----
From: Jay Michlin=20
Sent: Monday, June 25, 2007 4:28 PM
To: Brian DeForest
Cc: Sandrine Boulanger; Paul Hammer; Tim Gardner; Larry Scheer; Ken
Renshaw; Jerry Lopatin
Subject: Zonda submittal, volume testing, branching and related issues

Brian,

We discussed providing a submittal to QA so they can begin testing
Zonda. We subsequently had a discussion of providing a build so QA can
begin testing our ability to support at least 50 volumes. The latter
discussion raised the question of whether to test volume support in
Delorean or Zonda, and I subsequently encountered the same question in a
conversation with Sandrine.

It turns out that Ken and Larry had a conversation last week that
resolves these questions and allows us to move forward with testing
Zonda, and also testing volume support, without taking immediate action
about the Zonda branch. There is detail on the part of their overall
discussion that applies to our situation at
http://wiki/wiki/ONStor_Branch_Plan#How_do_we_get_there_from_here.3F

In summary, the first Zonda submittal comes from its own Zonda branch,
as exists today. If we want to test volume support using that submittal,
it is possible as soon as you decide what goes into it. Alternatively,
we can test volume support using Delorean.

If all goes well with the Zonda testing, the Zonda branch will then be
pushed to Main, and the Cougar branch will subsequently pull from Main.
Ultimately, the Cougar branch will become the "Dev" branch that runs in
parallel with Main to preserve Main's integrity. There is much more
detail at the wiki page referenced above.

Hopefully this email *answers* questions rather than raising new ones,
and if I got anything wrong, I'm sure Larry or Ken will help and correct
me. If this does answer some questions, the goal is that we should
provide a first submittal of Zonda to QA this week, and also we should
do whatever works best for QA to begin testing volume support as soon as
we can.

Please let me know if this is okay or if there is more to be discussed.
And thanks very much.

jay
