Open Stack

On Thu, Sep 25, 2014 at 01:52:48PM +0100, John Garbutt wrote:
> On 25 September 2014 11:44, Daniel P. Berrange <berrange at 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 :|