On Mon, Sep 29, 2014 at 5:23 AM, Gary Kotton <gkot...@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" <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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev