Open Stack

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: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.

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