On Thu, Sep 25, 2014 at 01:52:48PM +0100, John Garbutt wrote: > On 25 September 2014 11:44, Daniel P. Berrange <berra...@redhat.com> wrote: > > To use the runway system, we need to have a frequently updated list > > of blueprints which are a priority to review / merge. Once we have > > such a list, IMHO, adding the fixed runway slots around that does > > not do anything positive for me as a reviewer. If we have a priority > > list of blueprints that is accurate & timely updated, I'd be far > > more effective if I just worked directly from that list. > > I am proposing we do that for kilo-1 and kilo-2. > > > Please just focus on the maintaining > > the blueprint priority list. > > I am trying to. I clearly failed. > > > 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. > > 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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev