On Mon, Sep 29, 2014 at 4:46 PM, Christopher Yeoh <cbky...@gmail.com> wrote:
> On Mon, 29 Sep 2014 13:32:57 -0700 > Joe Gordon <joe.gord...@gmail.com> wrote: > > > 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 > > Am biased given I have a spec approved for Juno which we didn't quite > fully merge which we want to finish off early in Kilo (most of the > patches are very close already to being ready to merge), but I think we > should give priority to reviewing specs already approved in Juno and > perhaps only require one +2 for re-approval. > I like the idea of prioritizing specs that were previously approved and only requiring a single +2 for re-approval if there are no major changes to them. > > Otherwise we'll end up wasting weeks of development time just when > there is lots of review bandwidth available and the CI system is > lightly loaded. Honestly, ideally I'd like to just start merging as > soon as Kilo opens. Nothing has changed between Juno FF and Kilo opening > so there's really no reason that an approved Juno spec should not be > reapproved. > > Chris > > > > > > > > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev