On Fri, Mar 07, 2014 at 12:30:15PM +0100, 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.
It is fairly easy to spot when people submit things which are features,
without a blueprint or bug listed. So as long as reviewers make a god
habit of rejecting such patches I think people will get the message
fairly quickly.
> 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.
If nothing else, trying more formal review of blueprints in gerrit
for a cycle, should teach us more about what we'll want storyboard
to be able todo in this area.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
