X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C72285.84A89C64@onstor-exch02.onstor.net>; Mon, 18 Dec 2006 01:18:45 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C72285.84A89C64"
Content-class: urn:content-classes:message
Subject: RE: Cheetah soak running Clio RC2
Date: Mon, 18 Dec 2006 01:18:45 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E01336095@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Cheetah soak running Clio RC2
thread-index: AcchTR42d4oXwOZuQ2G+XQIuycaLqQADNtgnAANG0tAABgaX7AAAEGgQAAHo5YEAABc8QAAAo19KAB1kdPYAAICmdQAC9MS1AAfXHcgAA16AjAACFBY3AACIWG8ADALYwgADzKRw
References: <BB375AF679D4A34E9CA8DFA650E2B04ECAA58D@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E0A90E4@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04EC62540@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E578AD5@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E013D27D5@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E0A90E5@onstor-exch02.onstor.net>
From: "Ken Renshaw" <ken.renshaw@onstor.com>
To: "Larry Scheer" <larry.scheer@onstor.com>,
	"Paul Hammer" <paul.hammer@onstor.com>,
	"Jay Michlin" <jay.michlin@onstor.com>,
	"Caeli Collins" <caeli.collins@onstor.com>,
	"Narayan Venkat" <narayan.venkat@onstor.com>,
	"Tim Gardner" <tim.gardner@onstor.com>,
	"Sandrine Boulanger" <sandrine.boulanger@onstor.com>,
	"dl-Clio" <dl-Clio@onstor.com>
Cc: "Eric Barrett" <eric.barrett@onstor.com>,
	"Ed Kwan" <ed.kwan@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C72285.84A89C64
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



PH> So far I have not seen any workarounds suggested, like commenting =
out the SNMPD in the MCP tab or anything else. A compare after the =
install does not solve the problem, only identifies the problem without =
a proposal on how to fix it, i.e. what do we do when we know we have the =
problem in the field, call support/escalate?

LS> *** Perhaps you missed the step in my proposed workaround. It stated =
something like: etc., etc.

You missed the point, this workaround leaves it open for customers to =
misuse, or unfairly forces the escalation team to work on it instead of =
core dev where it should be, and as Caeli pointed out puts the onus of =
quality of release on the customers, which I agree is not a palatable =
solution. It's not so much that we at ONStor find the workaround =
desirable or not, but we need to be mindful that it's our customers =
perceptions that matter. I for one think that is a very important =
parameter and we need to change our perspective within engineering to =
address it. Engineering in a vacuum isn't that useful....

Simmply stating that 'we don't know' I find unacceptable, as evidently =
Paul and Caeli in this case do as well.  I think we can, and should, do =
better than this.

-Ken

------_=_NextPart_001_01C72285.84A89C64
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7650.28">
<TITLE>RE: Cheetah soak running Clio RC2</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<BR>

<P><FONT SIZE=3D2>PH&gt; So far I have not seen any workarounds =
suggested, like commenting out the SNMPD in the MCP tab or anything =
else. A compare after the install does not solve the problem, only =
identifies the problem without a proposal on how to fix it, i.e. what do =
we do when we know we have the problem in the field, call =
support/escalate?<BR>
<BR>
LS&gt; *** Perhaps you missed the step in my proposed workaround. It =
stated something like: etc., etc.<BR>
<BR>
You missed the point, this workaround leaves it open for customers to =
misuse, or unfairly forces the escalation team to work on it instead of =
core dev where it should be, and as Caeli pointed out puts the onus of =
quality of release on the customers, which I agree is not a palatable =
solution. It's not so much that we at ONStor find the workaround =
desirable or not, but we need to be mindful that it's our customers =
perceptions that matter. I for one think that is a very important =
parameter and we need to change our perspective within engineering to =
address it. Engineering in a vacuum isn't that useful....<BR>
<BR>
Simmply stating that 'we don't know' I find unacceptable, as evidently =
Paul and Caeli in this case do as well.&nbsp; I think we can, and =
should, do better than this.<BR>
<BR>
-Ken</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C72285.84A89C64--
