 So like documentation, the release cycle management is what we call an horizontal project in OpenStack. That means it serves the needs of all the other OpenStack projects. And so our main challenge, like Anne mentioned, is to accompany the constant growth of the OpenStack project and reinvent ways of doing what we do at the scale of software development that we see inside OpenStack. So my own program is called release cycle management and it's really about all the coordination around releases, around organizing the development and making sure that whatever we produce is consumable downstream. We have three different subteams on the next slide. So we have integrated release management, that's what the current release cycle is about. So we make sure that all the different pieces of the integrated release are on track and communicate what they are working on so that we can predict what will be in the next release and hit the deadlines on time and release on time on the same date. We announced at the beginning of the cycle, we have stable branch maintenance that goes after the release. That's about back porting important bug fixes, back porting security issues, security bug fixes and then issue point releases for our downstream consumers to use. And finally we have a team working on vulnerability management, receiving vulnerability reports from various actors on the Internet and following up on them and making sure that we address the vulnerabilities that are reported in OpenStack software as fast as we can and with the best disclosure mechanism as we can organize. So we'll start with what we achieved during the June cycle. So during the June cycle we hit all our deadlines again. So we released on the date we announced we would release. We evolved the process for publishing all the development milestones. We have three development milestones in the middle of the cycle and we used to have more of a branch for a few days and let it cool off. And we replaced that by a more lightweight system where we just tag when the project technically is happy with the current state of the branch, we just apply the tag and move forward. So we simplified that development milestone publication process. On the stable branch side we extended ICE house support for 15 months so we will be supporting ICE house for a 15 month period. And on the vulnerability management team front we addressed 90 vulnerability reports and issued 24 security adversaries out of those 90 reports. Some of them were not really vulnerabilities. Some others were not considered significant or exploitable enough for justifying an adversary but we released 24 adversaries during the last cycle. And finally we created a taxonomy for incident reports which means now when we receive a report we classify it and there is a given process to apply for each type of incident reports in that taxonomy. So we have a much more transparent process in the way we handle those reports. For the keto cycle first we'll start with stable branch because that's where most of the changes will be coming. So stable branches started to hit a scalability issue with the number of projects that we added to OpenStack so the reviews were really slow. There was a very small team driving the stable branches for all the projects. And we decided to decentralize this structure. So now we have a stable liaison named in every project that has a stable branch. So we have a designated person that lives in the upstream project that works in collaboration with the stable branch maintenance team. We have per project stable maintenance teams. So around the stable liaison we have a number of people that will directly approve the backports to the stable branch and that's a strong departure from the current system where it's a single team that was reviewing all the patches for all the projects and now we're decentralizing this organization so that we have project specific maintenance teams that are more in the domain expertise but we still have the stable branch maintenance team looking over them to make sure that they follow the stable branch rules, the rules that we created for the stable branch. We will have what we call stable champions. Those are people that are responsible for a branch in particular and making sure that that branch is still usable from a continuous integration perspective. Because from time to time the stable branch is not exercised as much as the master branch so it can go stale really, really fast. And when we need it like when we need to merge a security fix we kind of need it to be working on the right date. And the stable champion will watch the branch and make sure that we can land patches in that branch all the time. We'll have stable release managers. We already have them but we will more formalize how they're intervening in the structure. So stable release managers are people that are responsible for point releases so they bank the drum every month or every two months for issuing a specific point release in one of the stable branches and they make sure that all the important bug fixes are backported in time. And finally we'll have, in addition to the PR Project stable maintenance team, we'll have a stable core team that is responsible for answering the respect of the stable policy. So we have a stable policy that says only high impact bugs that are obviously backport compatible and will not result in behavior changes for users of the stable branch. So we have a very conservative stable branch policy and the stable core team is responsible for making sure that this continues to be respected with this more decentralized structure. So that's it for a stable branch. Oh no, we have more. We also try to introduce dependency capping in the stable branch. So currently we support new dependencies coming in the stable branch and this is the main reason why the stable branch breaks from time to time because there is a non-backport compatible dependency that gets pulled from the rest of our ecosystem. And so we are looking into ways to tap those dependencies to make sure that we don't get continuously broken by upgrading our dependencies. And finally we will work on opening the team because the team was operating on a separate mailing list and so it was really difficult for people outside the team to see the work that the stable branch team was doing and so we moved all our discussions to the development mailing list and we abandoned our specific mailing list to make sure that our work was visible so that we can recruit new people that would be interested in joining the stable branch team. Next slide please. So raise management. We will have feature freeze on the keto cycle on March 19. That means that will probably be the peak of feature landing and gate activity within OpenStack. So don't go in vacation around that date. For the final release, it's planned for April 30. So at the very end of the month of April and we'll have our next design summit in Vancouver in May. The challenge for the release management team is to handle one more project. We have Hyronic that was integrated at the end of the last cycle so we need to support it and it will be the first release of Hyronic in an OpenStack integrated release. We'll also do a number of changes in the release management processes. We'll switch to release liaison sync points. We used to have key health coming every Tuesday on the NRC channel to synchronize with release management and we'll more formally allow them to delegate to specific people within their team called the release liaison. We will then change, we already did change the release meeting that is every Tuesday at 21 UTC to become a true cross-project meeting. Any issue that is truly cross-project within OpenStack can be raised to that meeting to be discussed in an open forum, not just release management issues. So that's a nice improvement. We'll continue to evolve the design summit format to make sure that we can sustain more projects within the OpenStack community and to be discussed in the design summit. And finally, we'll also evolve tooling to support new practices. So lots of projects, for example, I've started to use SPEC for pre-approved design before implementation in OpenStack projects and we need to make sure that the SPEC process is as integrated as possible with the rest of our task tracking tools, Launchpad and the upcoming storyboard tool. On the vulnerability management front, we'll finish to publish the security advisories on a specific website. Currently, the security advisories are only published on an announce mailing list and we now have a repository for all the security advisories and we'll publish those directly on the security website on openstack.org. That will be more official than the copies that we would find on the Wiki currently. We plan to adopt a new vulnerability metric based on the Dread framework. So we'll be able to have a scale to rate the importance of every vulnerability. At least we'll try to provide a score that will be helpful for people to determine how fast they need to react to a given vulnerability. And I think that's it. Yes, thank you for listening and if you have any questions, please reach out to me on IRC, on Twitter or via email. Any questions on release cycle management?