[openstack-dev] [nova] Kilo Blueprints and Specs

John Garbutt john at johngarbutt.com
Thu Sep 25 12:52:48 UTC 2014


On 25 September 2014 11:44, Daniel P. Berrange <berrange at redhat.com> wrote:
> To use the runway system, we need to have a frequently updated list
> of blueprints which are a priority to review / merge. Once we have
> such a list, IMHO, adding the fixed runway slots around that does
> not do anything positive for me as a reviewer. If we have a priority
> list of blueprints that is accurate & timely updated, I'd be far
> more effective if I just worked directly from that list.

I am proposing we do that for kilo-1 and kilo-2.

> Please just focus on the maintaining
> the blueprint priority list.

I am trying to. I clearly failed.


The proposal is to keep kilo-1, kilo-2 much the same as juno. Except,
we work harder on getting people to buy into the priorities that are
set, and actively provoke more debate on their "correctness", and we
reduce the bar for what needs a blueprint.

We can't have 50 high priority blueprints, it doesn't mean anything,
right? We need to trim the list down to a manageable number, based on
the agreed project priorities. Thats all I mean by slots / runway at
this point.

Does this sound reasonable?


> The runways
> idea is just going to make me less efficient at reviewing. So I'm
> very much against it as an idea.

This proposal is different to the runways idea, although it certainly
borrows aspects of it. I just don't understand how this proposal has
all the same issues?


The key to the kilo-3 proposal, is about getting better at saying no,
this blueprint isn't very likely to make kilo.

If we focus on a smaller number of blueprints to review, we should be
able to get a greater percentage of those fully completed.

I am just using slots/runway-like ideas to help pick the high priority
blueprints we should concentrate on, during that final milestone.
Rather than keeping the distraction of 15 or so low priority
blueprints, with those poor submitters jamming up the check queue, and
constantly rebasing, and having to deal with the odd stray review
comment they might get lucky enough to get.


Maybe you think this bit is overkill, and thats fine. But I still
think we need a way to stop wasting so much of peoples time on things
that will not make it.


Thanks,
John



More information about the OpenStack-dev mailing list