[cgl_discussion] Validation Sub-team Meeting Minutes for 04/18/2002
rusty.lynch at intel.com
Fri Apr 19 11:32:01 PDT 2002
Validation Sub-team Meeting Minutes
Thursday April 18, 2002
· Craig Thomas (OSDL)
· Stephanie Glass (IBM)
· Julie Fleischer (Intel)
· Rusty Lynch (Intel)
· Rusty to talk with PoC chair (Khalid) about his strategy for
publishing the PoC website, and take this into consideration
on deciding the proper way to roll out the real validation
· Craig to write a better-phrased description for requirement
· Rusty to review requirements #15 through #35.x
· Craig to review requirements #50 through #56
· Julie to review requirements #70 through #70.5
· Change web site database so that a feature is associated with
a specific requirement
· Proposal for web site design:
o Previewed collaboration web site design and discussed the
implications on how the validation sub-team would do it's work
o A request was made to link each feature with a specific
With type of data, we create a web page the provided a matrix of
which requirements are covered by which validation suite
o Several new fields were brainstormed for tracking/reviewing
requirements. Each will need to be included in the web site
and the requirements tracking tool (i.e. the web page GUI to the
requirements tracking data.)
· Permanent location for validation sub-group web site:
o Discussed the different options available to the validation
These include hosting the site on an OSDL server with an
o It looks like the only other complex web site (i.e. needing
just some flashing text and a list of links) spawned by the
to be the site to be created by the PoC group. It makes a lot
for both CGLWG spawned sites to follow the same strategy.
o Whatever the end outcome, we need to resolve this very
· Process for reviewing requirements: A complete list of data to
capture on each
requirement is contained at the end of the minutes.
o Discussed our strategy for accomplishing coverage of the
The group agreed that a breadth verse depth decision needed to
case-by-case for each requirement. As a result, the new field
added to the requirements tracking table.
o The group will individually split up the requirements for
review, and then
provide the feedback to Rusty (or if the website comes up then
input the data to the tracking tool). Feedback will then be feed
the requirements group as official feedback from the validation
o Decided to add a field indicating owner ship, with an
associated URL for
requirements that are covered by external validation suites
group with not be touching).
o Decided to capture if the requirement requires a special
In the case of special configuration requirements, the OSDL lab
would be useful.
o Decided to capture if the requirement can be automated.
List of items to capture for each requirement: (Each of these will be
the requirements tracking
tool as soon
as it is updated.)
1. Available Suite (YES/NO): Is there an existing open source validation
that can be used to validate this requirement?
2. Testable (YES/NO): Is the requirement testable.
3. Traceable (YES/NO):
4. Complete (YES/NO): Is the requirement complete, or is there missing
For example, "networking must work" is not a
5. Effort (SMALL, MEDIUM, LARGE): Gut feel for how big an effort is required
validate this requirement. A requirement
all IPv6 RFC compliance would be 'LARGE',
requirement mandating the "/dev/watchdog"
work as documented in a reference
just a few features would be 'SMALL'. As
we learn more about
the specific requirement we might need to
adjust this value.
6. Coverage Strategy (DEPTH/BREADTH): Gut feel for how we should approach
this validation work.
As we learn more about the specific
requirement we might
need to adjust this value.
7. Ownership (OSDL, External): By ownership, I mean that this working group
will add a
validation suite to our framework, not that
we will need
to create a validation suite from scratch.
requirement #3.1 requires LSB compliance.
Our approach for
validating this requirement is to just have a
asking if the distribution has followed
LSB has set-up for proving compliance, so
running the automated
validation framework will not validate the
8. Special Configuration Required (YES/NO): Are there special configurations
that need to be
made before running an automated
Examples are all the
requirements having to do with
the various aspects of hot-swap
9. Can be Automated (YES/NO): Can an automated validation suite test this
10. Comments (free text): Any other important notations that can not be
contained in the
NOTE: Once we have this data in the database, we can query for types of
need feedback to the requirements group.
More information about the cgl_discussion