Open Stack

On Thu, Sep 25, 2014 at 11:27:09AM +0100, John Garbutt wrote:
> Hi,
> 
> A big thank you to jogo who has done a great job writing up plans for
> kilo blueprints and specs:
> 
> 1) Allow more code that doesn't need a blueprint and spec:
> https://review.openstack.org/#/c/116699/3
> 
> Specs are a heavy process, so hopefully this will strike a better
> balance between process and freedom. Basically it is forcing developer
> write documentation, which is always going to be painful.
> 
> 2) As a community, get project wide buy-in to blueprint priorities:
> https://review.openstack.org/#/c/112733/10
> 
> All attempts to do this have fallen flat of their face. The new summit
> structure should really help allow the right conversations to happen.
> 
> 
> I see two big remaining (inter-related) issues:
> * how to get more code merged into a Nova release
> * how to get better at saying no to stuff that will not fit
> 
> 
> There has been much discussion over getting more code into Nova, involving:
> * fix technical debt that is slowing us down
> * having sub-system (semi-)core reviewers, or similar
> * splitting up the code base more (after establishing firmer interfaces)
> I think we need a combination of all three, but I didn't want to go
> there in this thread.
> 
> 
> How do we get better at "saying no" ?
> 
> We have "politeness inversion" here. Leaving it to the last moment to
> tell people there code is not going to merge causes us lots of hidden
> overhead, and frustration all round. Honestly, clicking -2 on so much
> code that missed the feature freeze (and in many cases it was already
> approved) left me really quite depressed, and the submitters probably
> felt worse.
> 
> Discussion at the mid-cylce lead to the runway idea:
> https://review.openstack.org/#/c/112733
> 
> The main push back, are worries over process heaviness of the
> approach. The current spec process feels too heavy already, so adding
> more process is certainly a risk.
> 
> Here is a possible compromise:
> * only use the runway system for kilo-3
> 
> The idea being, we have a soft-ish feature freeze at the end of
> kilo-2, and make any blueprints targeted for kilo-3 go through a
> runway-like system, to help ensure what gets on there will get merged
> before the end of kilo-3.

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. The runways
idea is just going to make me less efficient at reviewing. So I'm
very much against it as an idea. Plesae just focus on the maintaining
the blueprint priority list.

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 :|