[openstack-dev] [all] The future of the integrated release

Stefano Maffulli stefano at openstack.org
Thu Aug 7 00:05:49 UTC 2014


On Wed 06 Aug 2014 02:10:23 PM PDT, Michael Still wrote:
>  - we rate limit the total number of blueprints under code review at
> any one time to a fixed number of "slots". I secretly prefer the term
> "runway", so I am going to use that for the rest of this email. A
> suggested initial number of runways was proposed at ten.

oooooh, I like the 'slots/runaway model'. Sounds to me like kan ban (in 
the Toyota sense not the hipster developer sense).

A light in my head just went on.

Let me translate what you're thinking about in other terms: the 
slot/runaway model would switch what is now a push model into a "pull" 
model. Currently we have patches coming in, pushed up for review. We 
have then on gerrit reviewers and core reviewers shuffling through 
these changesets, doing work and approve/comment. The reviewers have 
little to no way to notice when they're overloaded and managers have no 
way either. There is no way to identify when the process is suffering, 
slowing down or not satisfying demand, if not when the backlog blows 
up. As recent discussions demonstrate, this model is failing under our 
growth.

By switching to a model where we have a set of slots/runaway (buckets, 
in Toyota's terminology) reviewers would have a clear way to *pull* new 
reviews into their workstations to be processed. It's as simple as a 
supermaket aisle: when there is no more pasta on the shelf, a clerk 
goes in the backend and gets more pasta to refurbish the shelf. There 
is no sophisticated algorithm to predict demand: it's the demand of 
pasta that drives new pull requests (of pasta or changes to review).

This pull mechanism would help make it very visible where the 
bottlenecks are. At Toyota, for example, the amount of kanbans is the 
visible way to understand the capacity of the plant. The amount of 
slots/runaways would probably give us similar overview of the capacity 
of each project and give us tools to solve bottlenecks before they 
become emergencies.

I think you guys are on to something, I'd be very happy to formalize a 
proposal. Who should I talk to?

/stef



More information about the OpenStack-dev mailing list