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