[openstack-dev] [nova] review runways check-in and feedback

Jay Pipes jaypipes at gmail.com
Thu Jun 14 13:32:39 UTC 2018


On 06/13/2018 05:33 PM, Matt Riedemann wrote:
> On 6/13/2018 3:33 PM, melanie witt wrote:
>>
>> We've been experimenting with a new process this cycle, Review Runways 
>> [1] and we're about at the middle of the cycle now as we had the r-2 
>> milestone last week June 7.
>>
>> I wanted to start a thread and gather thoughts and feedback from the 
>> nova community about how they think runways have been working or not 
>> working and lend any suggestions to change or improve as we continue 
>> on in the rocky cycle.
>>
>> We decided to try the runways process to increase the chances of core 
>> reviewers converging on the same changes and thus increasing reviews 
>> and merges on approved blueprint work. As of today, we have 69 
>> blueprints approved and 28 blueprints completed, we just passed r-2 
>> June 7 and r-3 is July 26 and rc1 is August 9 [2].
>>
>> Do people feel like they've been receiving more review on their 
>> blueprints? Does it seem like we're completing more blueprints 
>> earlier? Is there feedback or suggestions for change that you can share?
> 
> Lots of cores are not reviewing stuff in the current runways slots, 
> which defeats the purpose of runways for the most part if the majority 
> of the core team aren't going to review what's in a slot.

I know I don't review a ton of stuff like you or Eric, but I just can't 
any more. It's too much for me to handle.

While I have tried to review a few of the runway-slotted efforts, I have 
gotten burned out on a number of them. Other runway-slotted efforts, I 
simply don't care enough about or once I've seen some of the code, 
simply can't bring myself to review it (sorry, just being honest).

I like the *concept* of the runways, though. It's good to have a 
focusing agent to direct reviewer attention to things that are "ready" 
for final review. Despite this focusing agent, though, we are still 
realistically limited by the small size of the Nova core team.

I'm not sure there are processes (runways or otherwise) that are going 
to increase the velocity of merging code [1] unless we increase the size 
of the core team.

It's not like we don't look for new core additions and attempt to 
identify folks that would be good cores and try to help them. We *do* do 
this.

The issue is that Nova is big, scary, messy, fragile (in many ways), 
complex and more than any other project (no offense to those other 
projects) has a virtually *endless* stream of feature requests coming 
(mostly from vendors, sorry) looking to plug their latest and greatest 
hardware into the virt world.

Until that endless stream of feature requests subsides, we will continue 
to have these problems. And, for those out there that say "well, Jay, 
then those vendors will just abandon OpenStack and go to more fertile 
feature-accepting grounds like k8s!", I say "hey, go for it."

Not everything is appropriate to jam into Nova (or OpenStack for that 
matter). Let k8s deal with the never-ending feature velocity (NFV) and 
vendor/product-enablement requests. And let them collapse under that weight.

</rant>

[1] I say "increase the velocity of merging code" but keep in mind that 
Nova *already* merges the most code in all of OpenStack. We merge more 
code in Nova in a week than some service projects merge in three months. 
Our rate of code merging in just Nova often rivals larger-scoped 
monoliths like kubernetes/kubernetes.

> Lots of people have ready-for-runways blueprint series that aren't 
> queued up in the runways etherpad, and then ask for reviews on those 
> series and I have to tell them, "throw it in the runways queue".
> 
> I'm not sure if people are thinking subteams need to review series that 
> are ready for wider review first, but especially for the placement 
> stuff, I think those things need to be slotted up if they are ready.

I can work with Eric to make sure placement patch series (for the 
required ones at least that are holding up other work) are queued up 
properly for runways. That said, I don't feel we are suffering from a 
lack of reviews in placement-land.

Is your concern that placement stuff is getting unfair attention since 
many of the patch series aren't in the runways? Or is your concern that 
you'd like to see *more* core reviews on placement stuff outside of the 
usual placement-y core reviewers (you, me, Alex, Eric, Gibi and Dan)?
> Having said that, it's clear from the list of things in the runways 
> etherpad that there are some lower priority efforts that have been 
> completed probably because they leveraged runways (there are a few 
> xenapi blueprints for example, and the powervm driver changes).

Wasn't that kind of the point of the runways, though? To enable "lower 
priority" efforts to have a chance at getting reviews? Or are you just 
stating here the apparent success of that effort?

Best,
-jay



More information about the OpenStack-dev mailing list