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 

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

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 

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
OpenStack-dev mailing list

Reply via email to