<div><span style="color: rgb(160, 160, 168);">On Thursday, March 6, 2014 at 11:09 AM, Russell Bryant wrote:</span></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>On 03/06/2014 01:05 PM, Sean Dague wrote:</div><blockquote type="cite"><div><div>One of the issues that the Nova team has definitely hit is</div><div>Blueprint overload. At some point there were over 150 blueprints.</div><div>Many of them were a single sentence.</div><div><br></div><div>The results of this have been that design review today is typically</div><div>not happening on Blueprint approval, but is instead happening once</div><div>the code shows up in the code review. So -1s and -2s on code review</div><div>are a mix of design and code review. A big part of which is that</div><div>design was never in any way sufficiently reviewed before the code</div><div>started.</div></div></blockquote><div><br></div><div>We certainly did better this cycle. Having a team of people do the</div><div>reviews helped. We have some criteria documented [1]. Trying to do</div><div>reviews the blueprint whiteboard is just a painful disaster of a workflow.</div><div><br></div><blockquote type="cite"><div><div>In today's Nova meeting a new thought occurred. We already have</div><div>Gerrit which is good for reviewing things. It gives you detailed</div><div>commenting abilities, voting, and history. Instead of attempting</div><div>(and usually failing) on doing blueprint review in launchpad (or</div><div>launchpad + an etherpad, or launchpad + a wiki page) we could do</div><div>something like follows:</div><div><br></div><div>1. create bad blueprint 2. create gerrit review with detailed</div><div>proposal on the blueprint 3. iterate in gerrit working towards</div><div>blueprint approval 4. once approved copy back the approved text</div><div>into the blueprint (which should now be sufficiently detailed)</div><div><br></div><div>Basically blueprints would get design review, and we'd be pretty</div><div>sure we liked the approach before the blueprint is approved. This</div><div>would hopefully reduce the late design review in the code reviews</div><div>that's happening a lot now.</div><div><br></div><div>There are plenty of niggly details that would be need to be worked</div><div>out</div><div><br></div><div>* what's the basic text / template format of the design to be</div><div>reviewed (probably want a base template for folks to just keep</div><div>things consistent). * is this happening in the nova tree (somewhere</div><div>in docs/ - NEP (Nova Enhancement Proposals), or is it happening in</div><div>a separate gerrit tree. * are there timelines for blueprint</div><div>approval in a cycle? after which point, we don't review any new</div><div>items.</div><div><br></div><div>Anyway, plenty of details to be sorted. However we should figure</div><div>out if the big idea has support before we sort out the details on</div><div>this one.</div><div><br></div><div>Launchpad blueprints will still be used for tracking once things</div><div>are approved, but this will give us a standard way to iterate on</div><div>that content and get to agreement on approach.</div></div></blockquote><div><br></div><div>I am a *HUGE* fan of the general idea. It's a tool we already use for</div><div>review and iterating on text. It seems like it would be a huge win.</div><div>I also think it would allow and encourage a lot more people to get</div><div>involved in the reviews.</div><div><br></div><div>I like the idea of iterating in gerrit until it's approved, and then</div><div>using blueprints to track status throughout development. We could</div><div>copy the text back into the blueprint, or just have a link to the</div><div>proper file in the git repo.</div><div><br></div><div>I think a dedicated git repo for this makes sense.</div><div>openstack/nova-blueprints or something, or openstack/nova-proposals if</div><div>we want to be a bit less tied to launchpad terminology.</div><div><br></div><div>If folks are on board with the idea, I'm happy to work on getting a</div><div>repo set up. The base template could be the first review against the</div><div>repo.</div><div><br></div><div>[1] <a href="https://wiki.openstack.org/wiki/Blueprints">https://wiki.openstack.org/wiki/Blueprints</a></div></div></div></span></blockquote><div>Funny, we actually had this very recommendation come out of the OpenStack Operators mini-summit this week. There are other people very interested in this approach for blueprints.</div><div><br></div><div>John</div><div> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>-- </div><div>Russell Bryant</div><div><br></div><div>_______________________________________________</div><div>OpenStack-dev mailing list</div><div><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>