This is TRULY a constructive suggestion. Time and again people have good ideas, 
but fail to
make them high-quality BPs, even being familiar with code base. The major 
reason lies in lacking 
of design experiences. Such a Gerrit-based design iteration will make the 
design and decision
process more productive, leading to high quality design outputs in earlier 
phases of work. 

Beyond the text/template format thing, several high-quality BP examples can be 
recommended, 
by core members, as references to follow. Especially those BPs have a brief and 
concrete summary, 
a descriptive and detailed wiki page and are finally approved and merged. Some 
analysis and 
comments could be added to highlight the excellence and value of those 
recommended BPs.

Thanks, Sean, for your suggestion! A BIG +1

-----Original Message-----
From: Sean Dague [mailto:s...@dague.net] 
Sent: Friday, March 07, 2014 2:05 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review & 
approval

One of the issues that the Nova team has definitely hit is Blueprint overload. 
At some point there were over 150 blueprints. Many of them were a single 
sentence.

The results of this have been that design review today is typically not 
happening on Blueprint approval, but is instead happening once the code shows 
up in the code review. So -1s and -2s on code review are a mix of design and 
code review. A big part of which is that design was never in any way 
sufficiently reviewed before the code started.

In today's Nova meeting a new thought occurred. We already have Gerrit which is 
good for reviewing things. It gives you detailed commenting abilities, voting, 
and history. Instead of attempting (and usually
failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or 
launchpad + a wiki page) we could do something like follows:

1. create bad blueprint
2. create gerrit review with detailed proposal on the blueprint 3. iterate in 
gerrit working towards blueprint approval 4. once approved copy back the 
approved text into the blueprint (which should now be sufficiently detailed)

Basically blueprints would get design review, and we'd be pretty sure we liked 
the approach before the blueprint is approved. This would hopefully reduce the 
late design review in the code reviews that's happening a lot now.

There are plenty of niggly details that would be need to be worked out

 * what's the basic text / template format of the design to be reviewed 
(probably want a base template for folks to just keep things consistent).
 * is this happening in the nova tree (somewhere in docs/ - NEP (Nova 
Enhancement Proposals), or is it happening in a separate gerrit tree.
 * are there timelines for blueprint approval in a cycle? after which point, we 
don't review any new items.

Anyway, plenty of details to be sorted. However we should figure out if the big 
idea has support before we sort out the details on this one.

Launchpad blueprints will still be used for tracking once things are approved, 
but this will give us a standard way to iterate on that content and get to 
agreement on approach.

        -Sean

--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to