AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080404161515.275aaa32@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<larry.scheer@onstor.com>,<tim.gardner@onstor.com>,<brian.stark@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	34529	BB375AF679D4A34E9CA8DFA650E2B04E056C952D@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 4 Apr 2008 16:17:51 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Larry Scheer" <larry.scheer@onstor.com>
Cc: "Tim Gardner" <tim.gardner@onstor.com>
Bcc: Brian Stark <brian.stark@onstor.com>
Subject: Re: Cougar beta and dev branch
Message-ID: <20080404161751.59c222b9@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E056C952D@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E056C952D@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Importance: high
X-Priority: 1 (Highest)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

At the end of the day, all we are debating is when to create the beta
branch.  The notion that we can do the beta from dev branch is a
non-starter: you have to branch.  That's been established by a
million development groups times a million releases.  You can't tell
developers with non-beta appropriate changes to just sit on them. This
is what the dev branch is for.  And you can't worry about developers
having to do integrations, that's not a terrible burden: realistically a
developer can only fix 2-3 bugs a day, max, and generally less than 10
per week, and that's if they are fairly easy changes. Taking 2 minutes
for each one to integrate it to another branch is not so terrible.

QA won't be testing the beta branch after release except for
isolated fixes that might go into it, which will only require one or
two people at most, for a short period: targeted functional testing.
So there's no reason to say that GA code won't be tested by QA: it's
what they'll be testing after beta is released.

Therefore the implication is that when QA stipulates that a release
candidate (submittal) is acceptable for release for beta, the branch is
made then, from the label created for the submittal in question.

There is, however, another issue which implies that branching earlier
is necessary, and that is that non-beta release appropriate changes
need to be going into dev before the event described above.  So then it
would be fine to start a beta branch now-ish (see below), and submittals
made from that branch.  Once beta is approved for release by QA,
submittals revert to being made from the dev branch again.

As far as I can tell, that works perfectly fine and solves all needs.

Picking the right time to branch is part art and part science.  But if
the perfect time is missed by a little bit one way or another, it's not
the end of the world.  I would say it is mostly dictated by when
developers need to start checking in code that won't go into the
beta release, and there is a bunch of stuff on that list, but I don't
know off hand when that is supposed to start, or if it has already.



 On Fri, 4 Apr 2008 15:10:36 -0700 "Larry Scheer"
<larry.scheer@onstor.com> wrote:

> Tim, Vikas,
>   Please review and see if I have covered the points from our meeting
> this morning. If I have over looked an area or left out some detail
> please feel free to add and modify.
> 
> Andy,
>    Tim and I want to bring you in on this conversation and get your
> thoughts to. Please review and  feel free to comment, add detail, and
> point out any areas needing change.

> Thanks,
> 
> Larry
> 
> A decision was made to create a branch for the Cougar Beta; I would
> like to revisit that decision. I recommend delaying the use of a beta
> branch until the product is ready to deliver. I propose creating the
> Beta Branch only when we have a submittal ready to deliver to a Beta
> customer.  At that point this branch will be used to create only
> patches and one-offs unique to a customer or fixes to try that we do
> not have in our mainline code.
> 
> The reason behind my proposal has to do with what Max mentioned in the
> last cougar development team meeting. I am in complete agree with
> him. 

I do not know what issue Max mentioned in the last Cougar meeting.  I
doubt it matters.  We all know Max is insane.

> Using code from the Cougar Beta branch will result in only Beta code
> being tested by QA and the customers and the code intended for GA only
> being looked at by QA at the end of the project and not at all by the
> customer.

It's trivially true that customers will test the code in the beta
release, which, yeah, comes from the beta branch, that's the whole idea.
But the notion that no code in the GA release will have been tested by
customers does not follow from that.  In reality, the GA release will
at the worst case be 80% of what's in beta, and probably more like
95%.  So, I would say that 80-95% of GA will have been tested by the
beta customers.

> The end result is we will have a higher quality Beta release by
> sacrificing quality of the GA code unless we test both branches on an
> on going basis.

> I have outlined the pros and cons of each approach below to help
> everyone understand the trade-offs that happen with each approach.
> 
> Requirements and reason for Beta branch
> 		Needs a stable code base that QA can test
> 		Want a high quality product shipped as Beta
> 
> Pros of Beta Branch
> 
> 		Once QA has a stable submittal QA can anticipate what
> tests to run and what areas to retest.
> 		Tightly restricted input from development.
> 		Lower churn, only changes made to code is for defects
> found in this branch less chance for regressions.
> 		Only code tested by QA sent to customers
> 		Beta customers get a more stable "higher Quality
> release.
> 		Patches, customer fixes and one-offs can be tested
> here with a smaller delta of changes between what the customer has
> and the "fix." 
> 		Decision to integrate customer changes into mainline
> development can be delayed, or backed out of development easily.
> 
> Cons of Beta Branch
> 
> 		Code intended for GA not tested unless QA splits
> resources to test both dev and Beta branch simultaneously
> 		QA does not have the resources to test both mainline
> development and Beta branch
> 		GA code not thoroughly tested by QA at the end of Beta
> 		Beta customers not testing code intended for GA
> 		Developers need to make changes in 2 branches (code
> merges)
> 		Developers need to build and test both development and
> Beta branch before submittal into each
> 		If there are integration problems between Beta code
> and GA code they go unnoticed.
> 
> Pros of using the Development branch for Beta
> 
> 		QA tests submittals that have GA candidate code
> 		Beta Customers testing code targeted for GA
> 		Single area for both GA fixes and Beta fixes
> 		Same submittal process used for QA and Beta releases
> 		Higher visibility to problems that arise
> 		Potential integration problems between fixes are
> noticed sooner
> 		Less demands on developers due to no code merges
> needed
> 
> 
> Cons of using the Development branch for Beta
> 
> 		Higher churn greater chance for instability
> 		Need a code freeze If check-ins are not restricted
> regressions are possible
> 		Need to restrict check-ins to P1 - P2 defects
> 		Solution needed for on-going development and lower
> priority bugs - suggestion use bridge branch
> 		If code development is not carefully monitored a
> regression cane be introduced that stops QA progress
> 
> Summary
> 
> To use a Beta branch to finalize the Beta release will result in code
> intended for GA going ignored unless we have the QA resources to test
> both a GA submittal and a Beta submittal. I doubt we have the
> resources to simultaneously test both. Releasing code from a Beta
> branch would also mean customers will not be testing code intended
> for GA. By continuing the submittal process with the development
> branch and restricting the code submittals to P1 and P2 bugs only we
> can have a high quality Beta release and have QA and customers
> testing  code intended for the Cougar GA. 
> 
