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.gord...@gmail.com> wrote: > > > 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 > > -- Rackspace Australia
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev