Open Stack

On Mon, Aug 11, 2014 at 10:30:12PM -0700, Joe Gordon wrote:
> On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery <mestery at mestery.com> wrote:
> > > I really like this idea, as Michael and others alluded to in above, we
> > are
> > > attempting to set cycle goals for Kilo in Nova. but I think it is worth
> > > doing for all of OpenStack. We would like to make a list of key goals
> > before
> > > the summit so that we can plan our summit sessions around the goals. On a
> > > really high level one way to look at this is, in Kilo we need to pay down
> > > our technical debt.
> > >
> > > The slots/runway idea is somewhat separate from defining key cycle
> > goals; we
> > > can be approve blueprints based on key cycle goals without doing slots.
> >  But
> > > with so many concurrent blueprints up for review at any given time, the
> > > review teams are doing a lot of multitasking and humans are not very
> > good at
> > > multitasking. Hopefully slots can help address this issue, and hopefully
> > > allow us to actually merge more blueprints in a given cycle.
> > >
> > I'm not 100% sold on what the slots idea buys us. What I've seen this
> > cycle in Neutron is that we have a LOT of BPs proposed. We approve
> > them after review. And then we hit one of two issues: Slow review
> > cycles, and slow code turnaround issues. I don't think slots would
> > help this, and in fact may cause more issues. If we approve a BP and
> > give it a slot for which the eventual result is slow review and/or
> > code review turnaround, we're right back where we started. Even worse,
> > we may have not picked a BP for which the code submitter would have
> > turned around reviews faster. So we've now doubly hurt ourselves. I
> > have no idea how to solve this issue, but by over subscribing the
> > slots (e.g. over approving), we allow for the submissions with faster
> > turnaround a chance to merge quicker. With slots, we've removed this
> > capability by limiting what is even allowed to be considered for
> > review.
> >
> 
> Slow review: by limiting the number of blueprints up we hope to focus our
> efforts on fewer concurrent things
> slow code turn around: when a blueprint is given a slot (runway) we will
> first make sure the author/owner is available for fast code turnaround.
> 
> If a blueprint review stalls out (slow code turnaround, stalemate in review
> discussions etc.) we will take the slot and give it to another blueprint.

This idea of fixed slots is not really very appealing to me. It sounds
like we're adding a significant amount of buerocratic overhead to our
development process that is going to make us increasingly inefficient.
I don't want to waste time wating for a stalled blueprint to time out
before we give the slot to another blueprint. On any given day when I
have spare review time available I'll just review anything that is up
and waiting for review. If we can set a priority for the things up for
review that is great since I can look at those first, but the idea of
having fixed slots for things we should review does not do anything to
help my review efficiency IMHO.

I also thing it will kill our flexibility in approving & dealing with
changes that are not strategically important, but none the less go
through our blueprint/specs process. There have been a bunch of things
I've dealt with that are not strategic, but have low overhead to code
and review and easily dealt with in the slack time between looking at
the high priority reviews. It sounds like we're going to loose our
flexibility to pull in stuff like this if it only gets a chance when
strategically imporatant stuff is not occupying a slot

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|