Open Stack

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
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150402/53afe446/attachment.pgp>