Open Stack

>Adding in such case more bureaucracy (specs) is not the best way to resolve team throughput issues...

I’d argue that  if fundamental design disagreements can be surfaced and debated at the design stage rather than first emerging on patch set XXX of an implementation, and be used to then prioritize what needs to be implemented then they do have a useful role to play.

Phil


From: Boris Pavlovic [mailto:bpavlovic at mirantis.com]
Sent: 28 August 2014 23:13
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

Joe,


This is a resource problem, the nova team simply does not have enough people doing enough reviews to make this possible.

Adding in such case more bureaucracy (specs) is not the best way to resolve team throughput issues...

my 2cents


Best regards,
Boris Pavlovic

On Fri, Aug 29, 2014 at 2:01 AM, Joe Gordon <joe.gordon0 at gmail.com<mailto:joe.gordon0 at gmail.com>> wrote:


On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh <alan.kavanagh at ericsson.com<mailto:alan.kavanagh at ericsson.com>> wrote:
I share Donald's points here, I believe what would help is to clearly describe in the Wiki the process and workflow for the BP approval process and build in this process how to deal with discrepancies/disagreements and build timeframes for each stage and process of appeal etc.
The current process would benefit from some fine tuning and helping to build safe guards and time limits/deadlines so folks can expect responses within a reasonable time and not be left waiting in the cold.


This is a resource problem, the nova team simply does not have enough people doing enough reviews to make this possible.

My 2cents!
/Alan

-----Original Message-----
From: Dugger, Donald D [mailto:donald.d.dugger at intel.com<mailto:donald.d.dugger at intel.com>]
Sent: August-28-14 10:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] Is the BP approval process broken?

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.

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.

I feel we need to change the process somehow.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786<tel:303%2F443-3786>

-----Original Message-----
From: Jay Pipes [mailto:jaypipes at gmail.com<mailto:jaypipes at gmail.com>]
Sent: Thursday, August 28, 2014 1:44 PM
To: openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140902/72df77f6/attachment.html>