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