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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
