I'd like another term as Nova PTL, if you'll have me. I feel Kilo has gone reasonably well for Nova -- our experiment with priorities has meant that we’ve got a lot of important work done. We have progressed well with cells v2, our continued objects transition, scheduler refactoring, and the v2.1 API. The introduction of the trivial bug review list at the mid-cycle meetup has also seen 123 bug fixes merged since the mid-cycle, which is a great start.
Kilo is our second release using specs, and I think this process is still working well for us -- we’re having fewer arguments at code review time about the fundamentals of design, and we’re signalling to operators much better what we’re currently working on. Throughout Kilo I wrote regular summaries of the currently approved specs, and that seems to have been popular with operators. We also pivoted a little in Kilo and created a trivial approval process for Kilo specs which either were very small, or previously approved in Juno. This released the authors of those specs from meaningless paperwork, and meant that we were able to start merging that work very early in the release cycle. I think we should continue with this process in Liberty. I think its a good idea also to examine briefly some statistics about specs: Juno: approved but not implemented: 40 implemented: 49 Kilo: approved but not implemented: 30 implemented: 32 For those previously approved in Juno, 12 were implemented in Kilo. However, we’ve now approved 7 specs twice, but not merged an implementation. I’d like to spend some time at the start of Liberty trying to work out what’s happening with those 7 specs and why we haven’t managed to land an implementation yet. Approving specs is a fair bit of work, so doing it and then not merging an implementation is something we should dig into. There are certainly priorities which haven’t gone so well in Kilo. We need to progress more on functional testing, the nova-network migration effort, and CI testing consistency our drivers. These are obvious things to try and progress in Liberty, but I don’t want to pre-empt the design summit discussions by saying that these should be on the priority list of Liberty. In my Kilo PTL candidacy email, I called for a “social approach” to the problems we faced at the time, and that’s what I have focussed on for this release cycle. At the start of the release we didn’t have an agreed plan for how to implement the specifics for the v2.1 API, and we talked through that really well. What we’ve ended up with is an implementation in tree which I think will meet our needs going forward. We are similarly still in a talking phase with the nova-network migration work, and I think that might continue for a bit longer -- the problem there is that we need a shared vision for what this migration will look like while meeting the needs of the deployers who are yet to migrate. Our velocity continues to amaze me, and I don’t think we’re going noticeably slower than we did in Juno. In Juno we saw 2,974 changes with 16,112 patchsets, and 21,958 reviews. In Kilo we have seen 2,886 changes with 15,668 patchsets and 19,516 reviews at the time of writing this email. For comparison, Neutron saw 11,333 patchsets and Swift saw 1,139 patchsets for Kilo. I’d like to thank everyone for their hard work during Kilo. I am personally very excited by what we achieved in Nova in Kilo, and I’m looking forwards to Liberty. I hope you are looking forward to our next release as well! Michael -- Rackspace Australia __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
