[openstack-dev] [all] The future of the integrated release
Eoghan Glynn
eglynn at redhat.com
Tue Aug 12 18:26:46 UTC 2014
> 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.
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.
Cheers,
Eoghan
More information about the OpenStack-dev
mailing list