[openstack-dev] [Nova] Blueprint review process

John Garbutt john at johngarbutt.com
Mon Oct 28 14:11:29 UTC 2013


On 25 October 2013 11:52, Nikola Đipanov <ndipanov at redhat.com> wrote:
> On 23/10/13 17:33, Russell Bryant wrote:
>> 4) Blueprint Prioritization
>> I would like to do a better job of using priorities in Icehouse.  The
>> priority field services a couple of purposes:
>>
>>   - helps reviewers prioritize their time
>>
>>   - helps set expectations for the submitter for how reviewing this
>>     work stacks up against other things
>>
>> In the last meeting we discussed an idea that I think is worth trying at
>> least for icehouse-1 to see if we like it or not.  The idea is that
>> *every* blueprint starts out at a Low priority, which means "best
>> effort, but no promises".  For a blueprint to get prioritized higher, it
>> should have 2 nova-core members signed up to review the resulting code.
>>

I am +1 the updated process.

On 25 October 2013 11:52, Nikola Đipanov <ndipanov at redhat.com> wrote:
> I don't have the numbers but I have a feeling that what happened in
> Havana was that a lot of blueprints slipped until the time for feature
> freeze. Reviewers thought it was a worthwile feature at that point (this
> was, I feel, when *actual* blueprint reviews are done - whatever the
> process says. It's natural too - once the code is there so much more is
> clear) and wanted to get it in - but it was late in the cycle so we
> ended up accepting things that could have been done better.

Maybe we need a clarification around the priority, something like:
* the priority applies only to the target milestone when the priority was agreed
* should the blueprint move to a new milestone, the priority should be
reset to low priority

> It would be good to levarage the blueprint process to make people post
> code as soon as possible IMHO. How about making posted code a pre-req
> for core reviewers to sign up for them? Thoughts?

Hmm, I like the idea of encouraging people to submit blueprints, and
get them reviewed, before starting to code. If we can help resolve
differences at the design phase, it should help make the code review a
much happier experience!

John



More information about the OpenStack-dev mailing list