Open Stack

On Wed, Aug 13, 2014 at 5:15 AM, Daniel P. Berrange <berrange at redhat.com> wrote:
> 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
>
I agree with all of Daniel's comments here, and these are the same
reason I'm not in favor of "fixed slots" or "runways." As ttx has
stated in this thread, we have done a really poor job as a project of
understanding what are the priority items for a release, and sticking
to those. Trying to solve that to put focus on the priority items,
while allowing for smaller, low-overhead code and reviews should be
the priority here.

Thanks,
Kyle

> 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 :|
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev