Open Stack

Hi,

Liberty-1 has been tagged and release, as such we have hit the
promised Spec Freeze.
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule

We discussed this at the nova-meeting yesterday, but here are more
specifics on how we try to track this process.

A) Liberty Priority Specs not frozen

As a community we committed to this priorities:
http://specs.openstack.org/openstack/nova-specs/priorities/liberty-priorities.html

To give them space, we have extended the spec freeze until 9th July.
So merge at will for the priority specs.

Lets be clear, committing to focusing on these priorities does mean
there are other things we will be unable to do, and that sucks, but
there are big limits on what we can get done right now.


B) Backlog specs still open

As we transition towards a new process for M, we are leaving the backlog open:
http://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html

Basically, we can merge any full or partial spec that look like it is
in scope for Nova:
http://docs.openstack.org/developer/nova/devref/project_scope.html

One issue, we have not yet decided the process for M, so there is no
clear route out of the backlog yet. I plan to have a solid proposal
after the mid-cylce.

We are still getting the hang of using backlog specs, so I expect that
to process to evolve as we go.


C) Why bother with a freeze?

We need to be honest about why we do what we do.

This is a very poor attempt at that, I will share more thoughts when I
share the proposal for the new spec process in the very near future.

* its what we normally do
Its a terrible reason, but I said I was going to be honest.
I understand the awesome power of unlearning things, but this is still
a thing. Habits and rhythm can be a useful tool, when it works.

* increasing the number of code reviews
Turns out spec reviews are hard, and time consuming, and doing too
many turns your brain to mush. If we keep focusing on spec reviews, we
have nova-core folks who are not doing code reviews, and focusing on
the stuff that really matters, getting code merged. Having a cut off
date to say, no don't bug me any more for spec reviews, means we can
concentrate on code reviews and getting things done.
Keeping the backlog open risks this distraction, but it seems like the
best tradeoff here, and worth trying.

* being honest about what will fit into liberty.
This is a poor way of doing that, but it is something we are trying to
do. We had lots of feedback that people wanted more upfront notice if
their thing was very unlikely to merge, rather than having them sit in
a massive review queue and get ignored in a frustrating passive
aggressive way. Review bandwidth is the big limit right now.


D) What is the spec freeze process?

Please note, all non-priority features need all their code up for
review by: 16th July, and need to be merged by 30th July (so we can
concentrate on the priority features and bug fixes).
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Dates_overview

If you don't want an exception, please convert your spec to a backlog
spec (see above).

Lets use Gerrit to vote on the specs. But please add your spec to this
list (as described in that etherpad):
https://etherpad.openstack.org/p/liberty-spec-freeze-exceptions

Please +1 or +2 a spec if you thing the spec is ready to merge, and
should get a feature freeze exception.

If you really don't want that spec in liberty for some reason, please
add a -1, with a very good reason why it would cause a problem.

Ideally we would have all spec exceptions voted on by 2nd July, and
will merge them all by 3rd July.

After that point, I will click abandon on all specs that are left
open, but not a backlog spec. That is just so the review queue is very
clear. Any submitter should easily be able to undo the abandon, unlike
a procedural -2. I will add a comment on that abandon that points to
this ML post to explain my self. I hope that keeps folks more
productive during this spec "hiatus".

Now things will crop up later in the release, and we can discuss those
in the nova-meeting as they crop up. For example a bug fix that needs
an API change, we can consider those as they crop up.


Any process questions, do catch me on #openstack-nova IRC
(johnthetubaguy) for a chat, as usual. As always, feedback and ideas
very welcome.

Thanks,
John