<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/13/2013 07:35 PM, Christopher
Yeoh wrote:<br>
</div>
<blockquote
cite="mid:CANCY3edE3L9kZgNNRwv3GdFFDZ6ABepgy8-XjJPr23-hPTr0sw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Nov 14, 2013 at 9:54 AM,
David Kranz <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:dkranz@redhat.com" target="_blank">dkranz@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">It was
clear at the summit that there is a pressing need for more
scenario tests. A number of folks have volunteered to
participate so we need a way to track progress and avoid
duplication. We have not had great satisfaction using
either bugs or blueprints, so Sean and I are proposing a
more "self-service" approach and process:<br>
<br>
1. Developer checks in the zeroth version of a scenario
test as work in progress. It contains a description of the
test, and possibly work items. This will "claim" the
area of the proposed scenario to avoid duplication and
allow others to comment through gerrit.<br>
</blockquote>
<div><br>
</div>
<div>I don't know how well it maps for scenario testing, but
I think the spreadsheet approach for the API tests has
worked pretty well. Makes the breakdown of large chunks of
work more manageable<br>
<br>
</div>
<div>Chris<br>
</div>
<div><br>
<br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
Yeah, I thought about that. It works well when the spec is a
collection of independent one-liners like it is for apis but
scenarios are more involved. I also like the idea of putting the
spec together with the code and the commenting utility of gerrit. We
thought it was worth a try.<br>
<br>
-David<br>
</body>
</html>