Open Stack

Hi,
Is the process documented anywhere? That is, if say for example I had a
spec approved in J and its code did not land, how do we go about kicking
the tires for K on that spec.
Thanks
Gary

On 9/29/14, 1:07 PM, "John Garbutt" <john at johngarbutt.com> wrote:

>On 27 September 2014 00:31, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>> On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt <john at johngarbutt.com>
>>wrote:
>>> On 25 September 2014 14:10, Daniel P. Berrange <berrange at redhat.com>
>>> wrote:
>>> >> The proposal is to keep kilo-1, kilo-2 much the same as juno.
>>>Except,
>>> >> we work harder on getting people to buy into the priorities that are
>>> >> set, and actively provoke more debate on their "correctness", and we
>>> >> reduce the bar for what needs a blueprint.
>>> >>
>>> >> We can't have 50 high priority blueprints, it doesn't mean anything,
>>> >> right? We need to trim the list down to a manageable number, based
>>>on
>>> >> the agreed project priorities. Thats all I mean by slots / runway at
>>> >> this point.
>>> >
>>> > I would suggest we don't try to rank high/medium/low as that is
>>> > too coarse, but rather just an ordered priority list. Then you
>>> > would not be in the situation of having 50 high blueprints. We
>>> > would instead naturally just start at the highest priority and
>>> > work downwards.
>>>
>>> OK. I guess I was fixating about fitting things into launchpad.
>>>
>>> I guess having both might be what happens.
>>>
>>> >> > The runways
>>> >> > idea is just going to make me less efficient at reviewing. So I'm
>>> >> > very much against it as an idea.
>>> >>
>>> >> This proposal is different to the runways idea, although it
>>>certainly
>>> >> borrows aspects of it. I just don't understand how this proposal has
>>> >> all the same issues?
>>> >>
>>> >>
>>> >> The key to the kilo-3 proposal, is about getting better at saying
>>>no,
>>> >> this blueprint isn't very likely to make kilo.
>>> >>
>>> >> If we focus on a smaller number of blueprints to review, we should
>>>be
>>> >> able to get a greater percentage of those fully completed.
>>> >>
>>> >> I am just using slots/runway-like ideas to help pick the high
>>>priority
>>> >> blueprints we should concentrate on, during that final milestone.
>>> >> Rather than keeping the distraction of 15 or so low priority
>>> >> blueprints, with those poor submitters jamming up the check queue,
>>>and
>>> >> constantly rebasing, and having to deal with the odd stray review
>>> >> comment they might get lucky enough to get.
>>> >>
>>> >> Maybe you think this bit is overkill, and thats fine. But I still
>>> >> think we need a way to stop wasting so much of peoples time on
>>>things
>>> >> that will not make it.
>>> >
>>> > The high priority blueprints are going to end up being mostly the big
>>> > scope changes which take alot of time to review & probably go through
>>> > many iterations. The low priority blueprints are going to end up
>>>being
>>> > the small things that don't consume significant resource to review
>>>and
>>> > are easy to deal with in the time we're waiting for the big items to
>>> > go through rebases or whatever. So what I don't like about the
>>>runways
>>> > slots idea is that removes the ability to be agile and take the
>>> > initiative
>>> > to review & approve the low priority stuff that would otherwise never
>>> > make it through.
>>>
>>> The idea is more around concentrating on the *same* list of things.
>>>
>>> Certainly we need to avoid the priority inversion of concentrating
>>> only on the big things.
>>>
>>> Its also why I suggested that for kilo-1 and kilo-2, we allow any
>>> blueprint to merge, and only restrict it to a specific list in kilo-3,
>>> the idea being to maximise the number of things that get completed,
>>> rather than merging some half blueprints, but not getting to the good
>>> bits.
>>>
>>
>> Do we have to decide this now, or can we see how project priorities go
>>and
>> reevaluate half way through Kilo-2?
>
>What we need to decide is not to use the runway idea for kilo-1 and
>kilo-2. At this point, I guess we have (passively) decided that now.
>
>I like the idea of waiting till mid kilo-2. Thats around Spec freeze,
>which is handy.
>
>Thanks,
>John
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev