[openstack-dev] [all] The future of the integrated release

Ian Wells ijw.ubuntu at cack.org.uk
Wed Aug 13 14:33:57 UTC 2014

On 13 August 2014 06:01, Kyle Mestery <mestery at mestery.com> wrote:

> On Wed, Aug 13, 2014 at 5:15 AM, Daniel P. Berrange <berrange at redhat.com>
> wrote:
> > This idea of fixed slots is not really very appealing to me. It sounds
> > like we're adding a significant amount of buerocratic overhead to our
> > development process that is going to make us increasingly inefficient.
> > I don't want to waste time wating for a stalled blueprint to time out
> > before we give the slot to another blueprint.
> >
> I agree with all of Daniel's comments here, and these are the same
> reason I'm not in favor of "fixed slots" or "runways." As ttx has
> stated in this thread, we have done a really poor job as a project of
> understanding what are the priority items for a release, and sticking
> to those. Trying to solve that to put focus on the priority items,
> while allowing for smaller, low-overhead code and reviews should be
> the priority here.

It seems to me that we're addressing the symptom and not the cause of the
problem.  We've set ourselves up as more of a cathedral and less of a
bazaar in one important respect: core reviewers are inevitably going to be
a bottleneck.  The slots proposal is simply saying 'we can't think a way of
scaling beyond what we have, and so let's restrict the inflow of changes to
a manageable level' - it doesn't increase capacity at all, it simply
improves the efficiency of using the current capacity and leaves us with a
hard limit that's fractionally higher than we're currently managing - but
we still have a capacity ceiling.

In Linux, to take another large project with significant feature velocity,
there's a degree of decentralisation.  The ultimate cores review code, but
getting code in depends more on a wider network of trusted associates.  We
don't have the same setup: even *proposed* changes have to be reviewed by
two cores before it's necessarily worth writing anything to make the change
in question.  Everything goes through Gerrit, which is one, centralised,
location for everyone to put in their code.

I have no great answer to this, but is there a way - perhaps via team
sponsorship from cores to ensure that the general direction is right, and
cloned repositories for purpose-specific changes, as one example - that we
can get an audience of people to check, try and test proposed changes long
before they need reviewing for final inclusion?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140813/e1f5bc7b/attachment.html>

More information about the OpenStack-dev mailing list