<div dir="ltr"><br><div class="gmail_extra">On 13 August 2014 06:01, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>></span> wrote:<br><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Aug 13, 2014 at 5:15 AM, Daniel P. Berrange <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote:<br>


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

<br></div><div>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.<br>

<br></div><div>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?<br>

-- <br></div><div>Ian.<br></div></div></div></div>