Open Stack

On Wed, Aug 13, 2014 at 4:26 AM, Eoghan Glynn <eglynn at redhat.com> wrote:
>
>> It seems like this is exactly what the slots give us, though. The core review
>> team picks a number of slots indicating how much work they think they can
>> actually do (less than the available number of blueprints), and then
>> blueprints queue up to get a slot based on priorities and turnaround time
>> and other criteria that try to make slot allocation fair. By having the
>> slots, not only is the review priority communicated to the review team, it
>> is also communicated to anyone watching the project.
>
> One thing I'm not seeing shine through in this discussion of slots is
> whether any notion of individual cores, or small subsets of the core
> team with aligned interests, can "champion" blueprints that they have
> a particular interest in.

I think that's because we've focussed in this discussion on the slots
themselves, not the process of obtaining a slot.

The proposal as it stands now is that we would have a public list of
features that are ready to occupy a slot. That list would the ranked
in order of priority to the project, and the next free slot goes to
the top item on the list. The ordering of the list is determined by
nova-core, based on their understanding of the importance of a given
thing, as well as what they are hearing from our users.

So -- there's totally scope for lobbying, or for a subset of core to
"champion" a feature to land, or for a company to explain why a given
feature is very important to them.

It sort of happens now -- there is a subset of core which cares more
about xen than libvirt for example. We're just being more open about
the process and setting expectations for our users. At the moment its
very confusing as a user, there are hundreds of proposed features for
Juno, nearly 100 of which have been accepted. However, we're kidding
ourselves if we think we can land 100 blueprints in a release cycle.

> For example it might address some pain-point they've encountered, or
> impact on some functional area that they themselves have worked on in
> the past, or line up with their thinking on some architectural point.
>
> But for whatever motivation, such small groups of cores currently have
> the freedom to self-organize in a fairly emergent way and "champion"
> individual BPs that are important to them, simply by *independently*
> giving those BPs review attention.
>
> Whereas under the slots initiative, presumably this power would be
> subsumed by the "group will", as expressed by the prioritization
> applied to the holding pattern feeding the runways?
>
> I'm not saying this is good or bad, just pointing out a change that
> we should have our eyes open to.

Michael

-- 
Rackspace Australia