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@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
