<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 29, 2014 at 5:23 AM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
Is the process documented anywhere? That is, if say for example I had a<br>
spec approved in J and its code did not land, how do we go about kicking<br>
the tires for K on that spec.<br></blockquote><div><br></div><div>Specs will need be re-submitted once we open up the specs repo for Kilo. The Kilo template will be changing a little bit, so specs will need a little bit of reworking. But I expect the process to approve previously approved specs to be quicker</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks<br>
<span><font color="#888888">Gary<br>
</font></span><div><div><br>
On 9/29/14, 1:07 PM, "John Garbutt" <<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>> wrote:<br>
<br>
>On 27 September 2014 00:31, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>> wrote:<br>
>> On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt <<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>><br>
>>wrote:<br>
>>> On 25 September 2014 14:10, Daniel P. Berrange <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>><br>
>>> wrote:<br>
>>> >> The proposal is to keep kilo-1, kilo-2 much the same as juno.<br>
>>>Except,<br>
>>> >> we work harder on getting people to buy into the priorities that are<br>
>>> >> set, and actively provoke more debate on their "correctness", and we<br>
>>> >> reduce the bar for what needs a blueprint.<br>
>>> >><br>
>>> >> We can't have 50 high priority blueprints, it doesn't mean anything,<br>
>>> >> right? We need to trim the list down to a manageable number, based<br>
>>>on<br>
>>> >> the agreed project priorities. Thats all I mean by slots / runway at<br>
>>> >> this point.<br>
>>> ><br>
>>> > I would suggest we don't try to rank high/medium/low as that is<br>
>>> > too coarse, but rather just an ordered priority list. Then you<br>
>>> > would not be in the situation of having 50 high blueprints. We<br>
>>> > would instead naturally just start at the highest priority and<br>
>>> > work downwards.<br>
>>><br>
>>> OK. I guess I was fixating about fitting things into launchpad.<br>
>>><br>
>>> I guess having both might be what happens.<br>
>>><br>
>>> >> > The runways<br>
>>> >> > idea is just going to make me less efficient at reviewing. So I'm<br>
>>> >> > very much against it as an idea.<br>
>>> >><br>
>>> >> This proposal is different to the runways idea, although it<br>
>>>certainly<br>
>>> >> borrows aspects of it. I just don't understand how this proposal has<br>
>>> >> all the same issues?<br>
>>> >><br>
>>> >><br>
>>> >> The key to the kilo-3 proposal, is about getting better at saying<br>
>>>no,<br>
>>> >> this blueprint isn't very likely to make kilo.<br>
>>> >><br>
>>> >> If we focus on a smaller number of blueprints to review, we should<br>
>>>be<br>
>>> >> able to get a greater percentage of those fully completed.<br>
>>> >><br>
>>> >> I am just using slots/runway-like ideas to help pick the high<br>
>>>priority<br>
>>> >> blueprints we should concentrate on, during that final milestone.<br>
>>> >> Rather than keeping the distraction of 15 or so low priority<br>
>>> >> blueprints, with those poor submitters jamming up the check queue,<br>
>>>and<br>
>>> >> constantly rebasing, and having to deal with the odd stray review<br>
>>> >> comment they might get lucky enough to get.<br>
>>> >><br>
>>> >> Maybe you think this bit is overkill, and thats fine. But I still<br>
>>> >> think we need a way to stop wasting so much of peoples time on<br>
>>>things<br>
>>> >> that will not make it.<br>
>>> ><br>
>>> > The high priority blueprints are going to end up being mostly the big<br>
>>> > scope changes which take alot of time to review & probably go through<br>
>>> > many iterations. The low priority blueprints are going to end up<br>
>>>being<br>
>>> > the small things that don't consume significant resource to review<br>
>>>and<br>
>>> > are easy to deal with in the time we're waiting for the big items to<br>
>>> > go through rebases or whatever. So what I don't like about the<br>
>>>runways<br>
>>> > slots idea is that removes the ability to be agile and take the<br>
>>> > initiative<br>
>>> > to review & approve the low priority stuff that would otherwise never<br>
>>> > make it through.<br>
>>><br>
>>> The idea is more around concentrating on the *same* list of things.<br>
>>><br>
>>> Certainly we need to avoid the priority inversion of concentrating<br>
>>> only on the big things.<br>
>>><br>
>>> Its also why I suggested that for kilo-1 and kilo-2, we allow any<br>
>>> blueprint to merge, and only restrict it to a specific list in kilo-3,<br>
>>> the idea being to maximise the number of things that get completed,<br>
>>> rather than merging some half blueprints, but not getting to the good<br>
>>> bits.<br>
>>><br>
>><br>
>> Do we have to decide this now, or can we see how project priorities go<br>
>>and<br>
>> reevaluate half way through Kilo-2?<br>
><br>
>What we need to decide is not to use the runway idea for kilo-1 and<br>
>kilo-2. At this point, I guess we have (passively) decided that now.<br>
><br>
>I like the idea of waiting till mid kilo-2. Thats around Spec freeze,<br>
>which is handy.<br>
><br>
>Thanks,<br>
>John<br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>