[openstack-dev] [qa] Clarification of policy for qa-specs around adding new tests

Kenichi Oomichi oomichi at mxs.nes.nec.co.jp
Tue Jun 17 01:45:55 UTC 2014


> -----Original Message-----
> From: Matthew Treinish [mailto:mtreinish at kortar.org]
> Sent: Monday, June 16, 2014 11:58 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [qa] Clarification of policy for qa-specs around adding new tests
> 
> 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.

+1 to use a single blueprint for adding new tests of each project.
The unified topic of each project would be useful to get each project
reviewers' effort on the Tempest tests reviews.
To add new tests, do we need to have qa-specs, or is it OK to have
blueprints only?

Thanks
Ken'ichi Ohmichi




More information about the OpenStack-dev mailing list