<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 13, 2014 at 2:01 AM, Nikola Đipanov <span dir="ltr"><<a href="mailto:ndipanov@redhat.com" target="_blank">ndipanov@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On 08/13/2014 04:05 AM, Michael Still wrote:<br>


> On Wed, Aug 13, 2014 at 4:26 AM, Eoghan Glynn <<a href="mailto:eglynn@redhat.com">eglynn@redhat.com</a>> wrote:<br>
>><br>
>>> It seems like this is exactly what the slots give us, though. The core review<br>
>>> team picks a number of slots indicating how much work they think they can<br>
>>> actually do (less than the available number of blueprints), and then<br>
>>> blueprints queue up to get a slot based on priorities and turnaround time<br>
>>> and other criteria that try to make slot allocation fair. By having the<br>
>>> slots, not only is the review priority communicated to the review team, it<br>
>>> is also communicated to anyone watching the project.<br>
>><br>
>> One thing I'm not seeing shine through in this discussion of slots is<br>
>> whether any notion of individual cores, or small subsets of the core<br>
>> team with aligned interests, can "champion" blueprints that they have<br>
>> a particular interest in.<br>
><br>
> I think that's because we've focussed in this discussion on the slots<br>
> themselves, not the process of obtaining a slot.<br>
><br>
> The proposal as it stands now is that we would have a public list of<br>
> features that are ready to occupy a slot. That list would the ranked<br>
> in order of priority to the project, and the next free slot goes to<br>
> the top item on the list. The ordering of the list is determined by<br>
> nova-core, based on their understanding of the importance of a given<br>
> thing, as well as what they are hearing from our users.<br>
><br>
> So -- there's totally scope for lobbying, or for a subset of core to<br>
> "champion" a feature to land, or for a company to explain why a given<br>
> feature is very important to them.<br>
><br>
> It sort of happens now -- there is a subset of core which cares more<br>
> about xen than libvirt for example. We're just being more open about<br>
> the process and setting expectations for our users. At the moment its<br>
> very confusing as a user, there are hundreds of proposed features for<br>
> Juno, nearly 100 of which have been accepted. However, we're kidding<br>
> ourselves if we think we can land 100 blueprints in a release cycle.<br>
><br>
<br>
</div></div>While I agree with motivation for this - setting the expectations, I<br>
fail to see how this is different to what the Swift guys seem to be<br>
doing apart from more red tape.<br>
<br>
I would love for us to say: "If you want your feature in - you need to<br>
convince us that it's awesome and that we need to listen to you, by<br>
being active in the community (not only by means of writing code of<br>
course)".<br>
<br>
I fear that slots will have us saying: "Here's another check-box for you<br>
to tick, and the code goes in", which in addition to not communicating<br>
that we are ultimately the ones who chose what goes in, regardless of<br>
slots, also shifts the conversation away from what is really important,<br>
and that is the relative merit of the feature itself.<br>
<br>
But it obviously depends on the implementation.<br></blockquote><div><br></div><div><br></div><div>Proposed implementation: <a href="https://review.openstack.org/#/c/112733/">https://review.openstack.org/#/c/112733/</a> </div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
N.<br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>