Open Stack

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.

During kilo-1 and kilo-2, we can use medium and high priority as a
runway list. But during kilo-1 and kilo-2, its a "soft" runway system,
i.e. we allow other blueprints to merge. We could aim to keep around 5
to 10 un-merged features in medium and higher priority slots, similar
to what was attempted in juno, but with more buy in and more open
discussion in nova-meetings.

So during kilo-3, we are adding priorities into the feature freeze
process. You get your blueprint, with core reviewers, signed up to one
of 10 or so slots. And you only get in a slot of it looks like we can
get it merged before feature freeze, meaning it was most likely up for
review in kilo-2. Once in a slot, the reviewers and submitter iterate
quite quickly to get that blueprint merged. All other blueprints will
be "un-approved" (leaving the spec approved), until they are given a
slot (basically because its the only toggle we a good ACL on).

We still keep the end of kilo-3 for the string, docs and requirement
freeze as normal, so things that don't need a blueprint, and are
feature-like can still be merged during kilo-3.

Why bother with any feature freeze at all? Well the hope is we use the
time to fix bugs and get through the massive backlog (including the
review backlog for bug fixes).


Thoughts? Does this feel like it strikes a good balance?


Thanks,
John