Open Stack

On 08/13/2014 04:05 AM, Michael Still wrote:
> 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.
> 

While I agree with motivation for this - setting the expectations, I
fail to see how this is different to what the Swift guys seem to be
doing apart from more red tape.

I would love for us to say: "If you want your feature in - you need to
convince us that it's awesome and that we need to listen to you, by
being active in the community (not only by means of writing code of
course)".

I fear that slots will have us saying: "Here's another check-box for you
to tick, and the code goes in", which in addition to not communicating
that we are ultimately the ones who chose what goes in, regardless of
slots, also shifts the conversation away from what is really important,
and that is the relative merit of the feature itself.

But it obviously depends on the implementation.

N.