Open Stack

On Mon, Sep 29, 2014 at 5:23 AM, Gary Kotton <gkotton at vmware.com> wrote:

> 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.
>

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


> 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140929/7bf0219a/attachment-0001.html>