Open Stack

On 04/16/2014 10:13 AM, Christopher Lefelhocz wrote:
> I love that we are getting feedback from deployers/operations/etc.  Thanks
> to all who have spoken up in support from that perspective.
> 
> On 4/16/14 4:02 AM, "Day, Phil" <philip.day at hp.com> wrote:
> 
>>>
>> They are intended to be high level designs rather than low level designs,
>> so no they don't have to include all of the implementation details.
>>
>> On the other hand they should provided not only the info required to
>> decide that the feature is worth implementing, but also enough details so
>> that the reviewers can agree on the overall design approach (to avoid
>> churn late in the implementation review) and cover a number of other
>> areas that can and should be considered before the implementation starts
>> but seem too often get overlooked and are quite hard to dig back out from
>> the code (like what is the impact going to be on an system that's already
>> running).   The template is specifically set up to try and prompt the
>> submitter to think about these issues, and I think that brings a huge
>> amount of value to this stage.  At the moment I'm seeing a number of
>> sections being answered as "None" when really this seems to be "don't
>> know" or "didn't think about that" - and I'm thinking that we should ask
>> for a simple one-line justification of why there is no impact.
> 
> There may be some consistency work needed.  I spent some time/text in
> justification around no security impact in a spec.  I was guided
> specifically that None was a better statement.

Yes, consistency is definitely something important that we should work
toward continuously.

For code review, we have a wiki page where we try to gather common
things to look for (lots still to capture, of course):

    https://wiki.openstack.org/wiki/ReviewChecklist

For blueprints, we captured review criteria last cycle on this page:

    https://wiki.openstack.org/wiki/Blueprints#Blueprint_Review_Criteria

But that's quite high level compared to what we have now.  I think the
best guide for consistency is all of the text we have in the template.


http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/template.rst

Hopefully we'll get better about how we use this guidance as we get more
experience reviewing against it.  Another consistency area we need to
keep an eye on is how these processes and critera are evolving in each
project.  The *-specs processes have evolved quickly, and we should try
to make sure we're not doing this drastically differently across projects.

-- 
Russell Bryant