On 6 March 2014 19:09, Russell Bryant <rbry...@redhat.com> 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.
+1 Se have improved this, but there were two key issues: * lots of blueprints still approved from before we started this * not relaying having tools to track what has happened >> 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. +1 > 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. +1 It would be good to have the reviews done my nova-core. We can leave nova-drivers (for the moment) for priority setting, etc. > 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. Sounds cool. We probably need a mass un-approve of all the blueprints in Nova, so all new blueprints in Juno go through the new process. I can take charge of that part, and helping with joining some of the dots and testing this out. John _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev