X-Sylpheed-Account-Id:1
S:andy.sharp@onstor.com
SCF:#mh/Mailbox/sent
X-Sylpheed-Sign:0
X-Sylpheed-Encrypt:0
X-Sylpheed-Privacy-System:
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E056C952D@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 4 Apr 2008 15:48:01 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Larry Scheer" <larry.scheer@onstor.com>
Cc: "Tim Gardner" <tim.gardner@onstor.com>
Subject: Re: Cougar beta and dev branch
Message-ID: <20080404154801.5c7f1d62@ripper.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E056C952D@onstor-exch02.onstor.net>
Organization: Onstor
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 can't tell developers with non-beta appropriate
changes to just sit on them.  This is what the dev branch is for.  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,
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 shouldn'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.
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 question which might imply that two branches
is acceptable, 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, and submittals made from
that branch, and once it is released, submittals revert to being made
from the dev branch again.

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




 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.

Shame on you for not including me in this discussion from the
beginning, since you both know I'm more experienced in these
matters than either one of you.

> 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.

> 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.

This is a statement with no foundation as far as I can tell.  What is
your basis for this claim?  QA will stop looking at beta code the
day is passes QA.

> 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.

Perhaps you should claim the likely result of your proposal after you
have more fully described it.

> 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. 
> 
