On Mon, Apr 21, 2014 at 01:17:37AM +0000, Kenichi Oomichi wrote: > > Hi Matthew, > > Thanks for doing this, > > > -----Original Message----- > > From: Matthew Treinish [mailto:mtrein...@kortar.org] > > Sent: Saturday, April 19, 2014 11:59 AM > > To: openstack-dev@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.
Yes it'll definitely be an adjustment period, it's a change in the current workflow that the current core reviewers are used to. We all need to remember to check the qa-specs repo regularly as well. I forgot to call that out in the original message, thanks for the reminder. I should probably make that section in the README a bit more clear. The intent of that step was twofold, firstly it was to bring attention to the specs review so that it will get the review attention it deserves. (similar to the critical reviews topic in every meeting) The second effect is that it should hopefully get the drafter more interactively involved with everyone. We would like people who are drafting the specs to not just disappear after writing one. So by making attending an IRC meeting a step in the approval process the hope was to get people more engaged who are drafting specs. One of the problems we've had with tempest BPs in the past is people draft vague BPs for some work and we never hear from them about it, and it just sits there. If you look at the current list of tempest BPs you'll see a quite a few BPs leftover from Icehouse in that category. (I'll go through and purge things sometime later in the cycle) The hope is that by making putting your spec proposal on the meeting agenda that these developers will get more involved with the community. The only hiccup with this item is that there are a couple of timezones which aren't covered by our 2 meeting times. We'll need to come up with a solution for those people so the requirement may end up becoming looser if it ever comes up. Thanks, Matt Treinish _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
