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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
