confirmed On 04/02/2015 02:20 AM, Michael Still wrote: > 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 >
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
