 Okay. Hello everyone. This is Thierry Carras and I'm the release cycle management PTIL, which means I'm leading the team that is working on release cycle management things. And if we look at the next slide, you'll see that we usually describe release cycle management like this, like six months ago I would have said we do integrated release management, we do the coordinated release at the end of the cycle where we produce on time the set of projects that were part of the integrated release, we do stable branch maintenance, and we also looked over the team that does vulnerability management in OpenStack. But that changed a lot in the new cycle and on the next slide you can see that there are a few words that are crossed. And the reason for that is we pushed a number of changes in the governance of the project. On the next slide you can see that there was a project structure reform that was put in place during the Keto cycle. And it can basically be summarized as big tent and tags. The big tent side of things is that we are now recognizing projects as being part of OpenStack if they help with the OpenStack mission and if they are developed in the OpenStack way, which is way more inclusive than the previous way of describing OpenStack more as an integrated release single product. Now it's more like a collection of projects that all help in the same problem space and are all developed with the same values. The second part of the reform is that while we are adding more projects inside OpenStack, we are also providing clearer information about those projects and provide more precise answers to the questions that our downstream consumers of that ecosystem will have. So rather than have a single answer and say, well, you're part of the integrated release or you're not part of the integrated release, we are now providing a much richer explanation of where a project does fit in the ecosystem and what type of attributes it has. So that project structure reform basically created a few differences. One of them is that it's way easier to create project teams now in OpenStack than it used to be. So on the next slide you can see that we've been forming a new team dedicated to security called the OpenStack security team, and that's the reunion of the previously called OpenStack security group which was a set of experts working on security architecture in OpenStack and the reunion management team which was part of the release cycle management team and that team handles incident vulnerabilities and makes sure that we issue patches for vulnerabilities found in OpenStack projects. So those two were pretty linked. They were acting pretty close but they were not an official OpenStack team until the big tent was set up. So now we have a single team called the OpenStack security team which is led by Robert Clark and that team has two subgroups, the previous OpenStack security group and the reunion management team. And they all have a single portal that lives at security.openstack.org so if you're interested in security things that's your way to go. So it's no longer part of the release management team. It's one of the changes we've made. The second change on the next slide is that we no longer have an open stack release per se. We no longer have this closed set of projects that make up the OpenStack product release every six months. We have a larger collection of projects that are all OpenStack projects. There are still, according to the release, at the end of a six months development cycle though. There will still be an OpenStack release at the end of the liberty cycle that we are currently in. But it's an opt-in release for all the projects in OpenStack that make a release at the end of the cycle. They can be part of this coordinated release at the end of the cycle. It's no longer a closed set that is excluding most projects from appearing inside the project that is available. We are also working on refining processes and tools so that they are more self-service. Since we'll have to support a lot more projects, we also need to make sure that it's way easier to do releases and to do them in a very common and streamlined way. So we are working a lot on the tools, on the processes so that every project can be more independent in the ways they are doing their releases. And what binds the demo is the development cycle. We still do a six months long development cycle. We are still organizing the development of OpenStack projects in six months increments. And that's what binds all those projects together. Next slide. We are seeing another change that we need to push in liberty, is we are switching release tracking from predicting to reporting. We used to try to predict what features and what is being worked on and when that will land in the next cycle. And during the last few cycles it was pretty unreliable. We did a pretty bad job at trying to predict what would be in a given milestone in a given version of the software. So rather than doing a very bad job at trying to predict what will be in the next milestone, next development milestones and next releases, we decided to do a much better job at reporting what was actually done during those milestones. And let groups that are more focused on the long term view like the product managers that are working on trying to get a more roadmap-like approach to what gets done in OpenStack let those people actually work on predicting the trends and the next future, next priorities for the development. So as far as release management goes, we are only tracking what gets done rather than trying to predict what will get done which makes our job a lot easier so we can replace the sync points we had with the PTLs every week with office hours. So the PTLs and the release liaisons for each project can join us during office hours and ask questions they have about release management rather than have set sync points every week which was extremely time consuming for the release management team. We also have a new page at status.openstack.org slash release which shows this new release tracking report and shows all the features that are being already landed in the current development cycle and what is in the pipeline coming up. Next slide. Yes, so with the release management, we have a number of changes we need to push due to that switch to not having an integrated release anymore. So we support more release models than we used to. A lot of projects want to now follow on the footsteps of SWIFT and do intermediary releases in the middle of the cycle. So we are enabling them to do so. It's a natural consequence of projects getting more mature and more stable. You can actually release more often and deliver new features to your user base rather than have to wait for six months at the end of the cycle. To that effect, we are pushing for separate versioning for components. That means since every project will be able to do intermediary releases, we need to have version numbers that enable them to do so. So rather than have these date-based version numbers that we had previously like 2015.1, we recently switched all projects to a new major version number based on the number of integrated releases they had in the past. So the next NOVA release, for example, will not be 2015.2 but 12.00. And that will let projects evolve at their own pace rather than the time-based pace. And we'll be more precise for going forward. Each project will be able to switch to a version number that describes better the number of releases they are making. We are working on streamlining the library release process which used to be a bit of a mess. Every project was releasing libraries, announcing them, maybe not announcing them, sometimes tracking other projects because they weren't releasing at the right moment. So the release management team is expanding so that we can handle the process of tagging new library releases and ensure that all the processes follow along the way. Next slide. So in summary, in the Liberty Development Cycle you will have projects following a six-month time-based cycle and those will have a number of development milestones. The first one is this week on Thursday. The next one is at the end of July. And the third one will be September 3rd and that coincides with feature freeze for those projects. Then they will do release candidates like we always did up to a final release on October 15, 2015. And at the same time we'll have projects like SWIFT and Ironic, maybe others that will do releases, intermediary releases as needed. And they will do a final Liberty release which will also be included in this final release of the Liberty Cycle on October 15. So you can see that you will have projects on one side that are more traditionally in very active development mode that can only do development milestones during the six-month cycle and projects that are slightly more mature which can do more usable intermediary releases and will have a final release in October as well. Next slide. So what makes that final release different is that we'll have a stable branch out of it. That means we'll maintain a branch where we can push back ports of bug fixes, important bug fixes, vulnerabilities. And only this final release, the final release of the Liberty Cycle will be supported like this. So if you have intermediary releases and you install them, you don't have the additional comfort of having a stable branch that you can get critical bug fixes out of. Those stable branches, there will only be one per development cycle, like I just said. We also have a single stable branch policy across them. We have a team which ensures that only appropriate fixes are merged into those branches. We make sure that we don't break backward compatibility, that we don't add new configuration options, we don't add new features, we make sure we don't change the database structure. So those fixes are relatively safe to apply. We have been questioning the interest of doing stable point releases on those stable branches. We traditionally did, at the moment in time, like two months after the kilo release, we planned to have a kilo point one, basically a tag for all the projects that were part of the integrated release to mark the passage of time, basically. And we don't think that has that much value anymore, and it's becoming more costly to organize due to having a lot more projects that do stable branches. So it's still being discussed on the main list, but we might switch to just maintaining stable branches rather than also doing stable point releases as well. As far as stable branch support phase go, Juno will be supported until the Liberty release, that's 12 months. And for the kilo release, the current plan is to support it for nine months. And the reason why is we have a pretty complex setup for handling requirements around stable branches. We hope to make fast progress in fixing that in the upcoming cycle. If we do fix it, then we'll be able to extend the kilo support period, the kilo stable branch period, up to 12 or 15 months, but the current plan is to play it safe and announce that we'll support it for nine months unless we manage to fix the world. Okay, to have the next slide. No, that's all. So that's all for release management. It's more changes than we used to do. And like I said, we've been ramping up new members in the team. Doug Elman has been joining as co-release manager for this cycle. We have a number of library release managers working on that streamlining library release process. And so that's a lot more than I used to present on those PTL webinars. I hope you found it interesting. And see you probably in six months.