Open Stack

It seems like a no-brainer to me to prioritise people who have been patient
with us.

How about we tag these re-proposals with a commit message tag people can
search for when they review? Perhaps "Previously-approved: Juno"?

Michael

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