AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080628163947.5129435d@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<paul.hammer@onstor.com>,<sandrine.boulanger@onstor.com>,<jonathan.goldick@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	0	BB375AF679D4A34E9CA8DFA650E2B04E080CB30F@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Sat, 28 Jun 2008 16:40:33 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Paul Hammer" <paul.hammer@onstor.com>
Cc: "Sandrine Boulanger" <sandrine.boulanger@onstor.com>, "Jonathan Goldick"
 <jonathan.goldick@onstor.com>, "Brian Stark" <brian.stark@onstor.com>
Subject: Re: submittal #28 beta - list of inclusions.latest
Message-ID: <20080628164033.71be00f2@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E080CB30F@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E09CB8423@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E080CB30F@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

The spinning started already.  The building is finished and the AT
should be starting soonish, so the sub. should be ready sometime tonight
or tomorrow morning.

On Sat, 28 Jun 2008 15:44:05 -0700 "Paul Hammer"
<paul.hammer@onstor.com> wrote:

> Sandrine,
>  
> I was assuming that 28 is what Andy proposed, the beta branch with
> the limited changes (no fix for the corrupion). Your reply stated
> that it would take until 7/11 to get it ready. If 28 can get spun
> today (what is holding up spinning it?) and you only need 5 days, all
> the better, would mean the refresh could be ready after the holiday
> weekend, folks could plan to refresh on 7/7, we save four days from
> what I have listed below as the dates but the milestones don't really
> change much if at all. -Paul
> 
> ________________________________
> 
> From: Sandrine Boulanger
> Sent: Sat 6/28/2008 3:32 PM
> To: Paul Hammer; Jonathan Goldick; Andy Sharp; Brian Stark
> Subject: RE: submittal #28 beta - list of inclusions.latest
> 
> 
> 
>  
> 
>  
> 
> ________________________________
> 
> From: Paul Hammer 
> Sent: Saturday, June 28, 2008 3:24 PM
> To: Sandrine Boulanger; Jonathan Goldick; Andy Sharp; Brian Stark
> Subject: RE: submittal #28 beta - list of inclusions.latest
> 
>  
> 
> Hey All,
> 
>  
> 
> Wanted to chime in with what I think may be our remaining milestones
> and make sure every thing are lining up for GA.
> 
>  
> 
> Think we need 30 days of beta run time at most sites
> 
> We need to have all MF defects addressed by 7/25
> 
> We need the QA backlog to be at 0 by 7/25 (ignoring Kegg MI defects)
> 
> I think we need to have all beta feedback by 7/25. This should be our
> beta end date.
> 
> We need two weeks of stressful validation on the GA candidate(s) from
> 7/25 - 8/8, of course fixing on failure any p1 -p2 issue surfacing
> during this stretch.
> 
> Ship date for GA looks like 8/8
> 
>  
> 
> If we agree on these dates and we do not believe that we can have sub
> 28 ready until 7/11 then we have to go to beta with 26 next week and
> do a beta refresh to 28 when it is ready. 
> 
> > or we can build sub#28 beta with the changes Andy listed yesterday,
> > testing should take 5 days max. If we would decide faster we could
> > have started this week-end!
> 
>  
> 
> We can even set this expectation with our customers and provide them
> with the date for the refresh and let them know what we are
> addressing for the refresh). Don't see anyway that we can delay the
> beta until 7/11.  
> 
> > no, that what not my proposal
> 
>  
> 
> Sandrine, can your team test 28 and the dev branch in parallel and
> make both the 7/11 fdate for the refresh and 8/8 date for GA?
> 
> > I don't know what would be in this sub28 if it's not the beta I
> > mentioned above.
> 
>  
> 
>  If you need to we can pull in other teams to help with the testing
> and to contribute their hw resources.
> 
>  
> 
> What do you all think?
> 
>  
> 
> -Paul
> 
>  
> 
> ________________________________
> 
> From: Sandrine Boulanger
> Sent: Sat 6/28/2008 3:00 PM
> To: Jonathan Goldick; Paul Hammer; Andy Sharp; Brian Stark
> Subject: RE: submittal #28 beta - list of inclusions.latest
> 
> 7/11 would be the earliest based on our schedules if we keep hitting
> the dates.
> 
> -----Original Message-----
> From: Jonathan Goldick
> Sent: Saturday, June 28, 2008 2:49 PM
> To: Sandrine Boulanger; Paul Hammer; Andy Sharp; Brian Stark
> Subject: Re: submittal #28 beta - list of inclusions.latest
> 
> But Paul asked about having the same level of confidence as beta1.
> There were many workflows that we didn't test for beta1.
> 
> -----Original Message-----
> From: Sandrine Boulanger
> To: Jonathan Goldick; Paul Hammer; Andy Sharp; Brian Stark
> Sent: Sat Jun 28 14:46:48 2008
> Subject: RE: submittal #28 beta - list of inclusions.latest
> 
> Because that's what the dev branch is, the GA branch.
> 
> -----Original Message-----
> From: Jonathan Goldick
> Sent: Saturday, June 28, 2008 2:46 PM
> To: Sandrine Boulanger; Paul Hammer; Andy Sharp; Brian Stark
> Subject: Re: submittal #28 beta - list of inclusions.latest
> 
> How can it be another month if the GA testing was supposed to be done
> by roughly that same time?
> 
> -----Original Message-----
> From: Sandrine Boulanger
> To: Paul Hammer; Andy Sharp; Brian Stark; Jonathan Goldick
> Sent: Sat Jun 28 09:28:48 2008
> Subject: RE: submittal #28 beta - list of inclusions.latest
> 
> another month
> 
> 
> -----Original Message-----
> From: Paul Hammer
> Sent: Fri 6/27/2008 9:16 PM
> To: Sandrine Boulanger; Andy Sharp; Brian Stark; Jonathan Goldick
> Subject: RE: submittal #28 beta - list of inclusions.latest
> 
> Sandrine,
> 
> 
> 
> No disclaimers, the product has to be a rock. How long would it take
> before we could make the Dev branch the next beta release branch? How
> many weeks of testing would be required to get to the same level of
> confidence that we have with sub26/beta?
> 
> 
> 
> Thanks,
> 
> 
> 
> -Paul
> 
> 
> 
> ________________________________
> 
> From: Sandrine Boulanger
> Sent: 2008-06-27 20:49
> To: Andy Sharp; Brian Stark; dl-Cougar Core Team
> Subject: RE: submittal #28 beta - list of inclusions.latest
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Andy Sharp
> Sent: Friday, June 27, 2008 7:57 PM
> To: Brian Stark; dl-Cougar Core Team
> Subject: submittal #28 beta - list of inclusions.latest
> 
> 
> 
> Team,
> 
> 
> 
> 
> 
> Here is the list of bugs/changes now proposed for sub28beta.  The
> 
> filesystem/corruption changes have been pulled from the list.  All the
> 
> changes currently on this list have been integrated to the beta branch
> 
> as of now.
> 
> 
> 
> Once all the changes were made to integrate the filesystem changes,
> Jon
> 
> and Jobi had no confidence in the viability of such a result.  The
> 
> amount of divergence from dev branch to cg_beta branch in the
> 
> filesystem code during the past several weeks has made such a three
> 
> way merge a risky proposition.
> 
> 
> 
> Software development's recommendation is to take the list of items
> 
> below, and then switch to dev/release branch from here on out.
> 
> > very risky, given the fact that we are only 25% or so through the
> > validation of this branch. Can we have a disclaimer then J?
> 
> 
> 
> 
> 
> 
> 
> The QA testing strategy for that would be a week of general
> functional testing
> 
> and regression of the fixed issues utilizing 2 clusters.  Consider
> that
> 
> option (A).
> 
> > do you mean for the list of changes below? I agree we need some
> > days to validate the beta build. That said, we need to be careful
> > with our QA resources if we don't want to impact GA.
> 
> 
> 
> There are only two other options worth putting out for team
> 
> consideration:
> 
> 
> 
> B) Merge all of the nfx-tree/code/sm-fs/ directory into the cg_beta
> 
> branch, and go from there.  Dev considers this to be more risky than
> 
> (A) but doable.  QA test results might be informative.
> 
> 
> 
> C) Try to put together a frankestein three way merge utilizing 3-ish
> 
> changelists from the dev branch to try to address the possibility of
> 
> corruption on a beta customer machine if they hit the right
> combination
> 
> of unclean volume shutdowns and log replays.  I believe I heard the
> 
> word "crazy" used when analyzing this option after seeing the first
> 
> attempt at creating the merged code.  QA test results would likely be
> 
> useless because the actual testing requirements would be unbounded.
> 
> This creature has not been compiled or unit tested.
> 
> 
> 
> 
> 
> Cheers,
> 
> 
> 
> a
> 
> 
> 
> 
> 
> It will contain fixes for at least the following issues:
> 
> 
> 
> > TED00024346 NFS perf. Occassionally drops to 0.
> 
> > wrong title for this defect, correct one is: FP crash in
> > fs_trylockSpin when running mirror tests
> 
> 
> 
> Change 29506 by jobia@jobi:jobi2 on 2008/06/03 10:26:26
> 
> 
> 
> > TED00024174 (8394 - Onstor) Several volume exceptions due
> 
> > to array issue     
> 
> 
> 
> LSI firmware WAR
> 
> Change 29760 by billn@billn-dev on 2008/06/18 15:40:58
> 
> 
> 
> > TED00024253     Csoak: Too many exceptions due to
> 
> > fs_volReadWriteQueue: Unable to send the read requests to the
> > storage
> 
> 
> 
> Send early response to ea for long log replays.
> 
> Change 29798 by jobia@jobi:jobi on 2008/06/20 15:30:03
> 
> 
> 
> > TED23467: Clean up messages at boot time 
> 
> 
> 
> Change 29427 by larrys@larrys-r14-dmip on 2008/05/27 11:42:00
> 
> Change 29566 by rendellf@rendellf-test on 2008/06/05 14:52:34
> 
> Change 29570 by rendellf@rendellf-test on 2008/06/05 21:06:15
> 
> 
> 
> 
> 
> Pending a small amount of testing by Raj on the nightly build of dev
> 
> branch, the following change will also go in:
> 
> > I think this sentence is a leftover from another email. Damon
> > tested the nightly build after Bill's fix was in. He ran into some
> > FP crash that was already known. Vikas do we have a conclusion for
> > that testing?
> 
> 
> 
> Change 29844 by billn@billn-dev on 2008/06/25 17:22:53
> 
> 
> 
>       Protection code added to make sure there is never a
> 
>       false positive on an I/O read or write operation.
> 
> 
> 
> 
> 
> > TED00024445 - Cougar read data performance problem
> 
> 
> 
> Change 29855 by maximk@maximk-13 on 2008/06/26 11:23:46
> 
>       24445 Do not hold spinlock while copying the data.
> 
> 
> 
