<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p>Sounds like you’re making progress and good decisions! My thoughts inline.<o:p></o:p></p>
<p>> <br>
> A. Sometimes the capability name doesn't really reflect the backing <br>
> test. Should we judge the intent of the capability, based on its name <br>
> (and hope that the backing tests will be fixed later), or judge solely <br>
> on the backing tests (and hope that the capability name will be fixed<br>
> later) ?<br>
<br>
<o:p></o:p></p>
<p>You are correct, the tests are define the capability. Improvements in Names are welcome. I’d love to see some short descriptions of the intent too. The current list was intended to bootstrap the process not be an absolute reference.<o:p></o:p></p>
<p><br>
<br>
> B. The "Complete" criteria is a bit of a misnomer. My understanding is <br>
> based on Rob's post on [1], where "Complete" reflects that the test is <br>
> valid across all configurations and deployment of OpenStack. Is that <br>
> the correct interpretation ? Some TC members have been looking at it <br>
> from a "is the feature behind this test complete, or still being improved"<br>
> angle, and I would like to confirm my interpretation is correct. Links <br>
> to reference documents are welcome.<br>
<br>
<o:p></o:p></p>
<p>Sorry to waffle on this. I think both definitions can be applied with an AND. A complete capability works in a broad set of cases (is not only for a single use case) AND is fully implemented.<o:p></o:p></p>
<p>I think that it’s prefect for the TC to focus on the second question – that’s very much where we have questions. If it’s not complete from the TC’s perspective then I’d be amazed if it was complete in the other sense.<o:p></o:p></p>
</div>
</body>
</html>