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 s...@dague.net / sean.da...@samsung.com http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev