Open Stack

Sean Dague wrote:
> 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.

Sounds like an interesting experiment, and a timely one as we figure out
how to do blueprint approval in the future with StoryBoard.

I'm a bit skeptical that can work without enforcing that changes
reference at least a bug or a blueprint, though. People who were too
lazy to create a single-sentence blueprint to cover for their feature
will definitely not go through a Gerrit-powered process, so the
temptation to fly your smallish features below the radar ("not worth
this whole blueprint approval thing") and just get them merged will be
high. I fear it will overall result in work being less tracked, rather
than more tracked.

FWIW we plan to enforce a bug reference / blueprint reference in changes
with StoryBoard, but it comes with autocreation of missing
bugs/blueprints (from the commit message) to lower the developer hassle.

That being said, don't let my skepticism go into the way of your
experimentation. We definitely need to improve in this area. I'd like to
have a cross-project session on feature planning/tracking at the Design
Summit, where we can brainstorm more ideas around this.

-- 
Thierry Carrez (ttx)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140307/80165761/attachment.pgp>