Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cosmos-dev] ER 216210 - Define COSMOS 1.0 hardware & softwareoperational guidelines, recommendations, and best practices

Title: COSMOS QA strategy - Operational criteria and the impact

Jimmy

 

This should be an i9 ER. QA’s holistic testing will depend on this ER and I believe that holistic testing will start during i9.

Regards
Shivashankari
Team Lead
India Technology Center
"If bugs were people then you would be China"


From: cosmos-dev-bounces@xxxxxxxxxxx [mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Mohsin, Jimmy
Sent: Wednesday, 23 January 2008 5:47 AM
To: Cosmos Dev
Subject: [cosmos-dev] ER 216210 - Define COSMOS 1.0 hardware & softwareoperational guidelines, recommendations, and best practices

 

All,

 

I have opened ER 216210 to address this email trail below.  I have marked this for i10.

 

Thanks,

Jimmy Mohsin

Cell   +1-609-635-1703

 

From: cosmos-dev-bounces@xxxxxxxxxxx [mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Mohsin, Jimmy
Sent: Tuesday, January 22, 2008 6:00 PM
To: Cosmos Dev
Subject: [cosmos-dev] COSMOS 1.0 - Recommended operational guidelines fromboth hardware & software perspectives

 

All,

 

Which is the right page to capture information that addresses the scenario painted below?  Specifically, I assume we need to publish the following information for COSMOS 1.0:

1.      Recommended hardware configuration(s)

2.      Recommended non-COSMOS software configuration(s)

3.      Recommended COSMOS software guidelines

 

Should this info go on http://wiki.eclipse.org/COSMOS_M2_Dependencies?

 

Thanks,

Jimmy Mohsin

Cell   +1-609-635-1703

 

From: cosmos-dev-bounces@xxxxxxxxxxx [mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Mohsin, Jimmy
Sent: Monday, January 14, 2008 3:57 PM
To: Cosmos Dev
Subject: [cosmos-dev] COSMOS QA strategy - Operational criteria and theimpact

 

Team,

As you know, we have been talking about the QA Criteria and strategy for a while now…  I had a question that came up internally in this regard…  Please consider the following points:

1.      We are yet to define / finalize our operational criteria for COSMOS 1.0.

2.      We are also yet to specify any kind of bounds on COSMOS 1.0, e.g. .. consider the following possibility:

a.      An adopter takes the COSMOS 1.0 code and deploys a Domain and Broker

b.      She then ties in TEN or so MDRs each with GIGABYTES worth of data

c.      She then executes a plethora of queries, each of which returns MEGABYTES of data. I paint this worst case scenario as we all know that there is NO shortage of LARGE existing data sources…

d.      Everything comes crashing down, and the adopter gets the impression that COSMOS has issues…

3.      In view of preventing the above from happening, let us say we have the operational criteria in place for i9; and then we discover that the code does not meet these criteria and has deficiencies that result in operational inefficiency

4.      In this (hopefully unlikely ???) scenario, re-factoring work would need to be done, which will result in downstream implications for our release timeframes.

How do we deal with this situation?  What else can we do to mitigate this risk, other than defining Operational Criteria?  Should we specify guidelines and operational best practices? Should we define hardware configurations? Anything else we should be thinking about?

Or am I being hopelessly pessimistic on a dark, rainy Monday and the adopter will never stress our system in any way shape or form?

Thanks,

Jimmy Mohsin

Cell   +1-609-635-1703


Back to the top