AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070516171828.53336df4@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<eric.barrett@onstor.com>,<jay.michlin@onstor.com>,<paul.hammer@onstor.com>,<tim.gardner@onstor.com>,<jerry.lopatin@onstor.com>,<caeli.collins@onstor.com>,<ed.kwan@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	BB375AF679D4A34E9CA8DFA650E2B04E03C0BD8E@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 16 May 2007 17:18:53 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Eric Barrett" <eric.barrett@onstor.com>
Cc: "Jay Michlin" <jay.michlin@onstor.com>, "Paul Hammer"
 <paul.hammer@onstor.com>, "Tim Gardner" <tim.gardner@onstor.com>, "Jerry
 Lopatin" <jerry.lopatin@onstor.com>, "Caeli Collins"
 <caeli.collins@onstor.com>, "Ed Kwan" <ed.kwan@onstor.com>
Subject: Re: Memo: 1.3.3 upgrade issue
Message-ID: <20070516171853.52c1a581@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E03C0BD8E@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E03C0BD44@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E03C0BD8E@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

I'm not advocating a release just for this, only that these changes be
put in, in the highly unlikely event that there is another.  BTW, I
don't know why this wasn't done originally, but perhaps there was an
argument not to do it back then and it sounded a lot like this one?
We're now up to 1.3.3.16.  It can't hurt.  Not putting those changes in
back then is causing us a lot of pain now.

I get conflicting information on 1.3.3.  Some say "...a few hardcore
customers..." while others say we have a bunch of customers still on it.

At the risk of repeating myself, I don't know of any good reason not to
do it.  It's really very little work.  The exact perforce CL#s were
identified back in February.

Thanks,

a

On Wed, 16 May 2007 16:43:32 -0700 "Eric Barrett"
<eric.barrett@onstor.com> wrote:

> I'd like to add that any field upgrade with 1.3.3's "system upgrade
> -s" has "system compare -s" run manually after it.   This is
> documented in the upgrade guide and the release notes, and is known
> by everybody in Support, both front- and backline.  If the "system
> compare" fails, the upgrade is attempted a second time, and if that
> fails, we usually go to some extreme measure like shipping a flash
> card we've burned manually.
> 
> We're pretty much done with 1.3.3.X except a few hardcore customers
> who refuse to move to 2.2 or have very very slow upgrade cycles (such
> as Time Inc.).  Those who are on it are on it and probably won't move
> to a new patch release.  At this stage of the game, the effort
> required to backport the fixes, even if moderate, may not outweigh
> the cost.  I'm not the one to make that call, of course, but if I
> were, I don't think I'd bother.
> 
> 
> 
> 
> -----Original Message-----
> From: Jay Michlin 
> Sent: Wednesday, May 16, 2007 4:17 PM
> To: Paul Hammer
> Cc: Eric Barrett; Andy Sharp; Tim Gardner; Jerry Lopatin; Caeli
> Collins Subject: FW: Memo: 1.3.3 upgrade issue
> 
> Paul,
> 
> We did indeed decide that these fixes to upgrade would go into 1.3.3
> in addition to Lambo. They cured stop-ship-class install file
> corruptions. I asked Eric about this a couple of weeks ago, and he
> was aware that the fixes did not go into 1.3.3. He also recalled that
> we committed to them there, specifically at CS request. He didn't
> know why the fixes never went in, and I don't either.
> 
> I think we need to do two things:
> 
> 1. Get these fixes into 1.3.3.x and into the field.
> 
> 2. Develop a process for following up and auditing items committed for
> patches. Right now I'm specifically concerned about the "upgrade to
> new flash format" we had planned for a "2.2.3" release. The Delorean
> core team requested this, and if that decision is to be reversed, it
> ought to require some process and discussion among those affected.
> 
> jay
> 
> 
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Wednesday, May 16, 2007 2:24 PM
> To: Jay Michlin
> Cc: Jerry Lopatin; Tim Gardner; Caeli Collins
> Subject: Memo: 1.3.3 upgrade issue
> 
> It's come to my attention that the upgrade fixes have never been
> integrated into the 1.3.3 branch, but that we continue to release
> "patches" or point-point releases from that branch.
> 
> I want to make it clear that there can be no good reason not to
> integrate these fixes.  The risk of file corruption when running the
> upgrade code in that branch is near 100%.  Even in the absence of
> exacerbating factors, like low memory condition,  the risk is still
> very high.  There's no reason to be taking this risk with our
> customers or our support resources.  The support implications of this
> problem are legion: random failures in any part of the system, often
> without any kind of telltale symptom.  I believe it's extremely
> likely we are taking a large support hit because of this, possibly
> without even knowing it.
> 
> Three months ago Development, Support and QA met and decided that
> these fixes were going into 1.3.3.10, but it didn't happen for some
> reason. Therefore I don't think we need to gather a core team meeting
> or anything, we just need to cut the red tape.
> 
> I don't know enough about the internal processes of this company to
> know who, but I strongly suggest that the right person(s) be directed
> to integrate those fixes into the 1.3.3 line.  It certainly won't
> hurt, and it might help a lot.
> 
> Thank you,
> 
> Andrew Sharp
