Open Stack

On 03/07/2014 06:30 AM, Thierry Carrez wrote:
> 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.

Honestly, right now we're not trying to fix all things (or enforce all
things). We're trying to fix a very specific issue that because we are
tool-failing on blueprint approval, as it's entirely impossible to have
a detailed conversation in launchpad, we're failing open with a bunch of
approved and targeted blueprints that no one understands what they are.

I want StoryBoard more than anyone else. However future Puppies and
Unicorns don't fix real problems right now. With the tools already at
our disposal, just using them a different way, I think we can fix some
real problems. I think, more importantly, we're going to discover a
whole new class of problems because we're not blocked on launchpad.

And the fact that the Nova team and the Ops team came up with the same
idea, independently, within a week of each other, is a reasonable
indication that it's worth trying. Because it seriously can't be worse
than the current model. :)

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

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