[openstack-dev] [nova] Is the BP approval process broken?
Jay Pipes
jaypipes at gmail.com
Thu Aug 28 21:02:20 UTC 2014
On 08/28/2014 04:42 PM, Dugger, Donald D wrote:
> I would contend that that right there is an indication that there's a
> problem with the process. You submit a BP and then you have no idea
> of what is happening and no way of addressing any issues. If the
> priority is wrong I can explain why I think the priority should be
> higher, getting stonewalled leaves me with no idea what's wrong and
> no way to address any problems.
>
> I think, in general, almost everyone is more than willing to adjust
> proposals based upon feedback. Tell me what you think is wrong and
> I'll either explain why the proposal is correct or I'll change it to
> address the concerns.
In many of the Gantt IRC meetings as well as the ML, I and others have
repeatedly raised concerns about the scheduler split being premature and
not a priority compared to the cleanup of the internal interfaces around
the resource tracker and scheduler. This feedback was echoed in the
mid-cycle meetup session as well. Sylvain and I have begun the work of
cleaning up those interfaces and fixing the bugs around non-versioned
data structures and inconsistent calling interfaces in the scheduler and
resource tracker. Progress is being made towards these things.
> Trying to deal with silence is really hard and really frustrating.
> Especially given that we're not supposed to spam the mailing it's
> really hard to know what to do. I don't know the solution but we
> need to do something. More core team members would help, maybe
> something like an automatic timeout where BPs/patches with no
> negative scores and no activity for a week get flagged for special
> handling.
Yes, I think flagging blueprints for special handling would be a good
thing. Keep in mind, though, that there are an enormous number of
proposed specifications, with the vast majority of folks only caring
about their own proposed specs, and very few doing reviews on anything
other than their own patches or specific area of interest.
Doing reviews on other folks' patches and blueprints would certainly
help in this regard. If cores only see someone contributing to a small,
isolated section of the code or only to their own blueprints/patches,
they generally tend to implicitly down-play that person's reviews in
favor of patches/blueprints from folks that are reviewing non-related
patches and contributing to reduce the total review load.
I understand your frustration about the silence, but the silence from
core team members may actually be a loud statement about where their
priorities are.
Best,
-jay
> I feel we need to change the process somehow.
>
> -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph:
> 303/443-3786
>
> -----Original Message----- From: Jay Pipes
> [mailto:jaypipes at gmail.com] Sent: Thursday, August 28, 2014 1:44 PM
> To: openstack-dev at lists.openstack.org Subject: Re: [openstack-dev]
> [nova] Is the BP approval process broken?
>
> On 08/27/2014 09:04 PM, Dugger, Donald D wrote:
>> I'll try and not whine about my pet project but I do think there is
>> a problem here. For the Gantt project to split out the scheduler
>> there is a crucial BP that needs to be implemented (
>> https://review.openstack.org/#/c/89893/ ) and, unfortunately, the
>> BP has been rejected and we'll have to try again for Kilo. My
>> question is did we do something wrong or is the process broken?
>>
>> Note that we originally proposed the BP on 4/23/14, went through
>> 10 iterations to the final version on 7/25/14 and the final version
>> got three +1s and a +2 by 8/5. Unfortunately, even after reaching
>> out to specific people, we didn't get the second +2, hence the
>> rejection.
>>
>> 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).
>
> Note that I'm not a core drivers team member.
>
> Best, -jay
>
>
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list