Open Stack

On 6 March 2014 19:09, Russell Bryant <rbryant at 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