 So pilot projects don't start knowing everything about open collaboration. They start having an interest in open collaboration and a willingness to learn and improve over time. So the process of moving from a pilot project to a confirmed project is not a single snap change. It's an evolution over time. And I think Starling X is a really great example of that as we see them demonstrating more and more of those success factors of open collaboration. So second announcement, the board has also approved Zuol as our second confirmed project. Zuol has been around for a, Zuol has been a central part of OpenStack's infrastructure for a very long time. But it also plays an important role in the whole story of open infrastructure because it makes it possible for unrelated open source projects using completely different build tools and testing workflows to do integrated testing across projects, which is really important for that integration story. So to give us an update, we have the Zuol project lead. Please welcome Jim Blair. Good morning. My name is James Blair. I'm one of the maintainers of the Zuol project, which, as you've heard, is a recently confirmed open infrastructure project under the foundation's CI, CCD, strategic focus area. We've been hard at work over the past six months adding new features to Zuol, but rather than talk about all of them, I'd like to focus on just one today. And it's one that I'm especially proud of because it's changing the way that we develop containerized software. First, you need to know something about Zuol. Zuol is more than continuous integration, and it's more than continuous deployment. It's a project gating system. And the key thing about a project gating system is it allows you to ask, what if? What if we make this change to our source code? What if we upgrade this dependency? What happens to the entire system if this microservice changes? What if our base container image changes? It's a new way of testing and it's a new way of development. It gives developers the freedom to experiment that was previously inconceivable. We call this process speculative execution. And Zuol has been doing it for years with Git. It allows developers to write changes to front-end interfaces, which depend on changes to back-end systems, which in turn rely on changes to underlying libraries. And we can see all of these changes working together before merging a single one to the source code repository. This helps developers work across projects within a team, across teams, or even across organizations. And now we're doing the same thing with containers. Container images are built on layers. And in a stacked image system, the registry is an intermediary between those layers. That means in order for a change in one image to appear and be used in a subsequent image, it first has to be published to the registry. This can lead to images appearing in production with inadequate testing or upstream images breaking downstream consumers. We need to know that changes to our base image are not going to break images that are built on top of it. With Zuol's speculative container images, registries are created as needed to present each test environment a view of the world as if all of the changes to all of the images ahead of it had already been merged and all of those images had already been published to an image registry. These registries are ephemeral. They last only as long as necessary for each test. And each deployment sees the complete future state of the world, including not only its own image, but all of the images that it depends on. This process is invisible to deployment tooling. In a test job, we simply configure the system to use Zuol's registry instead of the production image registry, and it automatically uses either the speculative or the current production image as appropriate. Once these images pass their testing and the developers review the underlying changes, because these registries contain the complete view of the world at that point, it is safe to promote the exact images used in testing into production. And this is a key design point for Zuol. Zuol is designed for you to be able to use your actual production deployment tooling in tests. Our aim is to make testing more like production, not the other way around. Zuol uses Ansible natively, and of course Ansible can drive any deployment system out there. Zuol lets you move fast without fear, because its speculative executions feature allows you to find issues and verify solutions in complex systems before committing a single change to production. If you're interested in learning more about Zuol this week, we have a number of talks scheduled. This is just a few of them. Please check the schedule for more. In particular, I'd like to draw your attention to the birds of a feather session, where if you have any questions about Zuol, we'll be happy to answer them in an informal environment. Thank you.