Open Stack

+1, we also need some work to clean existing blueprints which are not
approved.
 I think that is responsibility for drafter of those blueprints to follow
new process.

2014-03-07 2:05 GMT+08:00 Sean Dague <sean at dague.net>:

> 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.
>
>         -Sean
>
> --
> Sean Dague
> Samsung Research America
> sean at dague.net / sean.dague at samsung.com
> http://dague.net
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
ChangBo Guo(gcb)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140307/80a2b1f4/attachment.html>