Open Stack

I plan to start prioritising the specs that are in the review queue,
not just post approve.

We should fast track those that have already been approved, and
particularly when code is ready to go.

My original plan was to propose a git move from juno to kilo, so its
easy to see its just a re-approve. But this change alters that:
https://review.openstack.org/#/c/122109/

On 30 September 2014 02:43, Michael Still <mikal at stillhq.com> wrote:
> How about we tag these re-proposals with a commit message tag people can
> search for when they review? Perhaps "Previously-approved: Juno"?

Sure that could work.

Ideally also a link to the old juno spec in the references section
could help. Referencing it in here (after we tidy that up):
http://specs.openstack.org/openstack/nova-specs/

Linking to a WIP patch set in the review comments, might also help.

Thanks,
John


> On Tue, Sep 30, 2014 at 11:06 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>>
>>
>>
>> On Mon, Sep 29, 2014 at 4:46 PM, Christopher Yeoh <cbkyeoh at gmail.com>
>> wrote:
>>>
>>> On Mon, 29 Sep 2014 13:32:57 -0700
>>> Joe Gordon <joe.gordon0 at gmail.com> wrote:
>>>
>>> > 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
>>>
>>> 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" <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
>>> > >
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Rackspace Australia
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>