Open Stack

We started a retrospective for Oslo during our meeting last week. I promised to summarize the notes and start a thread here on the mailing list to make discussion easier. See [1] for the rough notes. Please follow up here, especially if you have any thoughts on things we can improve during kilo.

Things We Did Well
==================

We released 11 libraries with versions >= 1.0, including several updates to existing libraries, and 7 brand new libraries. Applying what we learned in past cycles where we released oslo.config and oslo.messaging, we have seen fairly rapid adoption of most of those libraries. We also started the graduation process for 3 other libraries, released updates to 3 others, and adopted pylockfile.

Counting existing libraries, graduations, and adoptions we are now managing 19 libraries.

Moving to separate a separate project group on launchpad has made tracking bugs and blueprints much simpler (thanks, Thierry!). We’ve also made good use of some etherpads and Google docs spreadsheets [2] to track our work, but I think we have room to improve here (see below).

The list of libraries we’re managing has grown, and so has the team. We have added several new members to our core teams, including Mike Bayer (zzzeek) on oslo.db and Yuriy Taraday (YorkSar) on oslo.concurrency. We have some other regular contributors who have been providing valuable input, both in code and in reviews, and I anticipate asking some of them to join the core teams during kilo.

Mehdi Abaakouk has taken over as our new lead maintainer for oslo.messaging. The transition is ongoing, but I count it as a success that we did not have to hunt very far for a good candidate. :-)

The liaison program we started this cycle has helped us identify blocking issues for adoption early, and improved our communication with the other project teams.

Things to Do Differently/Improve
================================

We learned this cycle that graduation work involves changes in many different repositories. Tracking the changes to know when a blueprint or bug is complete became difficult when we did not tag the commit correctly. During Kilo we should be more careful to always include the bug or blueprint reference in each commit message, and to use gerrit “topics” to make finding sets of changes across repositories easier.

We created 10 brand new libraries this cycle, but each has a few steps left before we can declare them officially “done”. The Google spreadsheet we created for auditing that work is a good way to visualize the status information, but updating it by hand is error-prone. Launchpad isn’t a great place to track a multi-step task like a graduation. I will keep looking for other solutions.

Although we have added team members in some places we still have a few libraries that need more reviewers. Taskflow, in particular, is evolving more slowly that we would like because of this. We need to find more specialist reviewers for some of the libraries.

We focused almost exclusively on graduations this cycle, as planned. However, that means we have a backlog of bug fixes and minor features to consider. Maybe we can focus on that work for a little while after we clean up the incubator?

We had fairly good attendance at our meeting, but I think we can probably find a time that is more convenient to more of the team. We should definitely talk about that as we head into kilo.



[1] https://etherpad.openstack.org/p/oslo-juno-retro
[2] https://docs.google.com/spreadsheets/d/1MvXsg0XxPonJ8yAFSraIwHM940eAfoXhfBVRa6hN7MY/edit#gid=0