[openstack-dev] [QA] qa-specs Repo and QA Program Juno Blueprint Review Process
Kenichi Oomichi
oomichi at mxs.nes.nec.co.jp
Mon Apr 21 01:17:37 UTC 2014
Hi Matthew,
Thanks for doing this,
> -----Original Message-----
> From: Matthew Treinish [mailto:mtreinish at kortar.org]
> Sent: Saturday, April 19, 2014 11:59 AM
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [QA] qa-specs Repo and QA Program Juno Blueprint Review Process
>
> Hi Everyone,
>
> Just like Nova [1] the QA program has adopted the proposal [2] to use gerrit to
> review blueprint specifications.
>
> The openstack/qa-specs repo is now ready for submissions. Changes are submitted
> to it like any other gerrit project. The README and a template for submitting
> new specifications can be found here:
>
> http://git.openstack.org/cgit/openstack/qa-specs/tree/README.rst
>
> http://git.openstack.org/cgit/openstack/qa-specs/tree/template.rst
>
> Please note that *all* Juno blueprints, including ones that were previously
> approved for a previous cycle, must go through this new process. This will
> help ensure that blueprints previously approved still make sense, as well as
> ensure that all Juno specs follow a more complete and consistent format. All
> outstanding Tempest blueprints from Icehouse have already been moved back into
> the 'New' state on Launchpad in preparation for a specification proposal using
> the new process.
>
> Everyone, not just tempest and grenade cores, should feel welcome to provide
> reviews and feedback on these specification proposals. Just like for code
> reviews we really appreciate anyone who takes the time to provide an insightful
> review.
>
> Since this is still a new process for all the projects I fully expect this
> process to evolve throughout the Juno cycle. But, I can honestly say that we
> have already seen positive effects from this new process even with only a
> handful of specifications going through the process.
I have experienced this process on not only QA but also Nova, that is nice
to get feedbacks from the other area developers. In addition, this process
enforces each writer need to consider/show merit, demerit and alternatives.
That would be nice to get a consensus of each blueprint, I prefer this process.
Just one concern is this process would block the developments if we cannot
get enough reviewers for qa-specs. Now there are few blueprints on qa-specs
and it is easy to review all of them. But if many bps on qa-specs, it would
be difficult to review all, I guess. The part of this is already mentioned
on http://git.openstack.org/cgit/openstack/qa-specs/tree/README.rst#n43
and I guess we need to figure out the review progresses in IRC meetings.
Thanks
Ken'ichi Ohmichi
More information about the OpenStack-dev
mailing list