Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140929/3bfd0c21/attachment.html>