Open Stack

On Wed, Aug 13, 2014 at 2:01 AM, Nikola Đipanov <ndipanov at redhat.com> wrote:

> 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.
>


Proposed implementation: https://review.openstack.org/#/c/112733/


> N.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140813/d9196f02/attachment.html>