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" <j...@johngarbutt.com> wrote: >On 27 September 2014 00:31, Joe Gordon <joe.gord...@gmail.com> wrote: >> On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt <j...@johngarbutt.com> >>wrote: >>> On 25 September 2014 14:10, Daniel P. Berrange <berra...@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@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev