Open Stack

On Thursday, March 6, 2014 at 11:09 AM, Russell Bryant wrote:
> On 03/06/2014 01:05 PM, 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.
> > 
> 
> 
> We certainly did better this cycle. Having a team of people do the
> reviews helped. We have some criteria documented [1]. Trying to do
> reviews the blueprint whiteboard is just a painful disaster of a workflow.
> 
> > 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.
> > 
> 
> 
> I am a *HUGE* fan of the general idea. It's a tool we already use for
> review and iterating on text. It seems like it would be a huge win.
> I also think it would allow and encourage a lot more people to get
> involved in the reviews.
> 
> I like the idea of iterating in gerrit until it's approved, and then
> using blueprints to track status throughout development. We could
> copy the text back into the blueprint, or just have a link to the
> proper file in the git repo.
> 
> I think a dedicated git repo for this makes sense.
> openstack/nova-blueprints or something, or openstack/nova-proposals if
> we want to be a bit less tied to launchpad terminology.
> 
> If folks are on board with the idea, I'm happy to work on getting a
> repo set up. The base template could be the first review against the
> repo.
> 
> [1] https://wiki.openstack.org/wiki/Blueprints
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.

John
 
> 
> -- 
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org (mailto:OpenStack-dev at lists.openstack.org)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140306/774f1a67/attachment.html>