Open Stack

On 08/28/2014 02:25 PM, Jay Pipes wrote:
> On 08/28/2014 04:05 PM, Chris Friesen wrote:
>> On 08/28/2014 01:44 PM, Jay Pipes wrote:
>>> On 08/27/2014 09:04 PM, Dugger, Donald D wrote:
>>
>>>> I understand that reviews are a burden and very hard but it seems wrong
>>>> that a BP with multiple positive reviews and no negative reviews is
>>>> dropped because of what looks like indifference.
>>>
>>> I would posit that this is not actually indifference. The reason that
>>> there may not have been >1 +2 from a core team member may very well have
>>> been that the core team members did not feel that the blueprint's
>>> priority was high enough to put before other work, or that the core team
>>> members did have the time to comment on the spec (due to them not
>>> feeling the blueprint had the priority to justify the time to do a full
>>> review).
>>
>> The overall "scheduler-lib" Blueprint is marked with a "high" priority
>> at "http://status.openstack.org/release/".  Hopefully that would apply
>> to sub-blueprints as well.
>
> a) There are no sub-blueprints to that scheduler-lib blueprint

I guess my terminology was wrong.  The original email referred to 
"https://review.openstack.org/#/c/89893/" as the "crucial BP that needs 
to be implemented".  That is part of 
"https://review.openstack.org/#/q/topic:bp/isolate-scheduler-db,n,z", 
which is listed as a Gerrit topic in the "scheduler-lib" blueprint that 
I pointed out.

> b) If there were sub-blueprints, that does not mean that they would
> necessarily take the same priority as their parent blueprint

I'm not sure how that would work.  If we have a high-priority blueprint 
depending on work that is considered low-priority, that would seem to 
set up a classic priority inversion scenario.

> c) There's no reason priorities can't be revisited when necessary

Sure, but in that case it might be a good idea to make the updated 
priority explicit.

Chris