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
