On Wed, Aug 13, 2014 at 2:01 AM, Nikola Đipanov <ndipa...@redhat.com> wrote:
> On 08/13/2014 04:05 AM, Michael Still wrote: > > On Wed, Aug 13, 2014 at 4:26 AM, Eoghan Glynn <egl...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
