On Mon, Jun 16, 2014 at 10:46:51AM -0400, David Kranz wrote: > I have been reviewing some of these specs and sense a lack of clarity around > what is expected. In the pre-qa-specs world we did not want tempest > blueprints to be used by projects to track their tempest test submissions > because the core review team did not want to have to spend a lot of time > dealing with that. We said that each project could have one tempest > blueprint that would point to some other place (project blueprints, > spreadsheet, etherpad, etc.) that would track specific tests to be added. > I'm not sure what aspect of the new qa-spec process would make us feel > differently about this. Has this policy changed? We should spell out the > expectation in any event. I will update the README when we have a > conclusion. >
The policy has not changed. There should be 1 BP (or maybe 2 or 3 if they want to split the effort a bit more granularly for tracking different classes of tests, but still 1 BP series) for improving project tests. For individual tests part of a bigger effort should be tracked outside of the Tempest LP. IMO after it's approved the spec/BP for tracking test additions is only really useful to have a unified topic to use for review classification. Also, to be fair I'm not sure things were clear before we moved to specs. When I cleaned up the BP list at the beginning of the cycle there were a couple of BPs on the list which didn't conform to this. -Matt Treinish
pgp7KB5jXHLqU.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
