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

Mark McLoughlin markmc at redhat.com
Wed Aug 13 13:08:09 UTC 2014

On Tue, 2014-08-12 at 14:12 -0700, Joe Gordon wrote:

> Here is the full nova proposal on  "Blueprint in Kilo: Runways and
> Project Priorities"
> https://review.openstack.org/#/c/112733/
> http://docs-draft.openstack.org/33/112733/4/check/gate-nova-docs/5f38603/doc/build/html/devref/runways.html

Thanks again for doing this.

Four points in the discussion jump out at me. Let's see if I can
paraphrase without misrepresenting :)

  - ttx - we need tools to be able to visualize these runways

  - danpb - the real problem here is that we don't have good tools to 
    help reviewers maintain a todo list which feeds, in part, off 
    blueprint prioritization

  - eglynn - what are the implications for our current ability for 
    groups within the project to self-organize?

  - russellb - why is different from reviewers sponsoring blueprints, 
    how will it work better?

I've been struggling to articulate a tooling idea for a while now. Let
me try again based on the runways idea and the thoughts above ...

When a reviewer sits down to do some reviews, their goal should be to
work through the small number of runways they're signed up to and drive
the list of reviews that need their attention to zero.

Reviewers should be able to create their own runways and allow others
sign up to them.

The reviewers responsible for that runway are responsible for pulling
new reviews from explicitly defined feeder runways.

Some feeder runways could be automated; no more than a search query for
say "new libvirt patches which aren't already in the libvirt driver

All of this activity should be visible to everyone. It should be
possible to look at all the runways, see what runways a patch is in,
understand the flow between runways, etc.

There's a lot of detail that would have to be worked out, but I'm pretty
convinced there's an opportunity to carve up the review backlog, empower
people to help out with managing the backlog, give reviewers manageable
queues for them to stay on top of, help ensure that project priorization
is one of the drivers of reviewer activity and increases contributor
visibility into how decisions are made.


More information about the OpenStack-dev mailing list