<div dir="ltr">It seems like a no-brainer to me to prioritise people who have been patient with us.<div><br></div><div>How about we tag these re-proposals with a commit message tag people can search for when they review? Perhaps "Previously-approved: Juno"?</div><div><br></div><div>Michael<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 30, 2014 at 11:06 AM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Sep 29, 2014 at 4:46 PM, Christopher Yeoh <span dir="ltr"><<a href="mailto:cbkyeoh@gmail.com" target="_blank">cbkyeoh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, 29 Sep 2014 13:32:57 -0700<br>
Joe Gordon <<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>> wrote:<br>
<br>
> On Mon, Sep 29, 2014 at 5:23 AM, Gary Kotton <<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>><br>
> wrote:<br>
><br>
> > Hi,<br>
> > Is the process documented anywhere? That is, if say for example I<br>
> > had a spec approved in J and its code did not land, how do we go<br>
> > about kicking the tires for K on that spec.<br>
> ><br>
><br>
> Specs will need be re-submitted once we open up the specs repo for<br>
> Kilo. The Kilo template will be changing a little bit, so specs will<br>
> need a little bit of reworking. But I expect the process to approve<br>
> previously approved specs to be quicker<br>
<br>
</span>Am biased given I have a spec approved for Juno which we didn't quite<br>
fully merge which we want to finish off early in Kilo (most of the<br>
patches are very close already to being ready to merge), but I think we<br>
should give priority to reviewing specs already approved in Juno and<br>
perhaps only require one +2 for re-approval.<br></blockquote><div><br></div></span><div>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.</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Otherwise we'll end up wasting weeks of development time just when<br>
there is lots of review bandwidth available and the CI system is<br>
lightly loaded. Honestly, ideally I'd like to just start merging as<br>
soon as Kilo opens. Nothing has changed between Juno FF and Kilo opening<br>
so there's really no reason that an approved Juno spec should not be<br>
reapproved.<br>
<br>
Chris<br>
<div><div><br>
><br>
><br>
> > Thanks<br>
> > Gary<br>
> ><br>
> > On 9/29/14, 1:07 PM, "John Garbutt" <<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>> wrote:<br>
> ><br>
> > >On 27 September 2014 00:31, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>><br>
> > >wrote:<br>
> > >> On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt<br>
> > >> <<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>><br>
> > >>wrote:<br>
> > >>> On 25 September 2014 14:10, Daniel P. Berrange<br>
> > >>> <<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>> wrote:<br>
> > >>> >> The proposal is to keep kilo-1, kilo-2 much the same as juno.<br>
> > >>>Except,<br>
> > >>> >> we work harder on getting people to buy into the priorities<br>
> > >>> >> that are set, and actively provoke more debate on their<br>
> > >>> >> "correctness", and we reduce the bar for what needs a<br>
> > >>> >> blueprint.<br>
> > >>> >><br>
> > >>> >> We can't have 50 high priority blueprints, it doesn't mean<br>
> > >>> >> anything, right? We need to trim the list down to a<br>
> > >>> >> manageable number, based<br>
> > >>>on<br>
> > >>> >> the agreed project priorities. Thats all I mean by slots /<br>
> > >>> >> runway at this point.<br>
> > >>> ><br>
> > >>> > I would suggest we don't try to rank high/medium/low as that<br>
> > >>> > is too coarse, but rather just an ordered priority list. Then<br>
> > >>> > you would not be in the situation of having 50 high<br>
> > >>> > blueprints. We would instead naturally just start at the<br>
> > >>> > highest priority and work downwards.<br>
> > >>><br>
> > >>> OK. I guess I was fixating about fitting things into launchpad.<br>
> > >>><br>
> > >>> I guess having both might be what happens.<br>
> > >>><br>
> > >>> >> > The runways<br>
> > >>> >> > idea is just going to make me less efficient at reviewing.<br>
> > >>> >> > So I'm very much against it as an idea.<br>
> > >>> >><br>
> > >>> >> This proposal is different to the runways idea, although it<br>
> > >>>certainly<br>
> > >>> >> borrows aspects of it. I just don't understand how this<br>
> > >>> >> proposal has all the same issues?<br>
> > >>> >><br>
> > >>> >><br>
> > >>> >> The key to the kilo-3 proposal, is about getting better at<br>
> > >>> >> saying<br>
> > >>>no,<br>
> > >>> >> this blueprint isn't very likely to make kilo.<br>
> > >>> >><br>
> > >>> >> If we focus on a smaller number of blueprints to review, we<br>
> > >>> >> should<br>
> > >>>be<br>
> > >>> >> able to get a greater percentage of those fully completed.<br>
> > >>> >><br>
> > >>> >> I am just using slots/runway-like ideas to help pick the high<br>
> > >>>priority<br>
> > >>> >> blueprints we should concentrate on, during that final<br>
> > >>> >> milestone. Rather than keeping the distraction of 15 or so<br>
> > >>> >> low priority blueprints, with those poor submitters jamming<br>
> > >>> >> up the check queue,<br>
> > >>>and<br>
> > >>> >> constantly rebasing, and having to deal with the odd stray<br>
> > >>> >> review comment they might get lucky enough to get.<br>
> > >>> >><br>
> > >>> >> Maybe you think this bit is overkill, and thats fine. But I<br>
> > >>> >> still think we need a way to stop wasting so much of peoples<br>
> > >>> >> time on<br>
> > >>>things<br>
> > >>> >> that will not make it.<br>
> > >>> ><br>
> > >>> > The high priority blueprints are going to end up being mostly<br>
> > >>> > the big scope changes which take alot of time to review &<br>
> > >>> > probably go through many iterations. The low priority<br>
> > >>> > blueprints are going to end up<br>
> > >>>being<br>
> > >>> > the small things that don't consume significant resource to<br>
> > >>> > review<br>
> > >>>and<br>
> > >>> > are easy to deal with in the time we're waiting for the big<br>
> > >>> > items to go through rebases or whatever. So what I don't like<br>
> > >>> > about the<br>
> > >>>runways<br>
> > >>> > slots idea is that removes the ability to be agile and take<br>
> > >>> > the initiative<br>
> > >>> > to review & approve the low priority stuff that would<br>
> > >>> > otherwise never make it through.<br>
> > >>><br>
> > >>> The idea is more around concentrating on the *same* list of<br>
> > >>> things.<br>
> > >>><br>
> > >>> Certainly we need to avoid the priority inversion of<br>
> > >>> concentrating only on the big things.<br>
> > >>><br>
> > >>> Its also why I suggested that for kilo-1 and kilo-2, we allow<br>
> > >>> any blueprint to merge, and only restrict it to a specific list<br>
> > >>> in kilo-3, the idea being to maximise the number of things that<br>
> > >>> get completed, rather than merging some half blueprints, but<br>
> > >>> not getting to the good bits.<br>
> > >>><br>
> > >><br>
> > >> Do we have to decide this now, or can we see how project<br>
> > >> priorities go<br>
> > >>and<br>
> > >> reevaluate half way through Kilo-2?<br>
> > ><br>
> > >What we need to decide is not to use the runway idea for kilo-1 and<br>
> > >kilo-2. At this point, I guess we have (passively) decided that<br>
> > >now.<br>
> > ><br>
> > >I like the idea of waiting till mid kilo-2. Thats around Spec<br>
> > >freeze, which is handy.<br>
> > ><br>
> > >Thanks,<br>
> > >John<br>
> > ><br>
> > >_______________________________________________<br>
> > >OpenStack-dev mailing list<br>
> > ><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> > ><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Rackspace Australia
</div></div></div>