 All right. Thanks for coming. Sorry we got started late. I got distracted by the beautiful baby, who is also now, I believe, an ATC. So welcome. I'm Clint Byron, my work for IBM. I have only 10 minutes, probably less, because they're going to cut me off. So I'm just going to go really fast and talk about Bonnie CI, which is a CI service offered developers of open source projects so you can develop like OpenStack develops. So what's our inspiration? Well, our team at IBM was deploying OpenStack, and we actually deployed Zool to test it and to do all of our development work. So we had cross-reprogated CI enabled by Zool, which is extremely popular in the OpenStack developers in the house. All right. You love Zool, right? Maybe even don't even know what Zool is. It's the thing that tests all your patches really fast and lands patches really fast. It's amazing. And our developers at IBM recognized that. And we had a lot of people come to us after our project was over and say, well, whatever happened with the project, we loved the CI system. So could we have that going forward? And we said no. Because the reality is it's actually a big deal. And we need to think about this. And we need to actually test it with more projects because maybe it's just special to IBM. So we decided let's make Bonnie CI and let's expose it just to open source projects on GitHub. So what we're missing with some of the other popular alternatives, right? You have like CircleCI and Travis. You could just run your own Jenkins. You can run your own bamboo. You can run that boat thing, which I always forget the name of. Anybody know? So what's missing is that they don't do a lot of great parallel testing, some of them, Jenkins. But CircleCI and Travis will certainly spin up lots of cloud resources to test your things. They also don't automatically gait their mergers. So you can gait things, and you can write your own bot. You can even gait things with Jenkins. But this becomes a giant pipeline problem, which OpenSack actually recognized, and that's why Zul was created. Almost none of them, maybe none of them, have cross-repo dependencies. So one of the cool things about Zul is you can be landing patch in this repository. And when it breaks, you say, oh, that's broken in that repository. So you can say, I depend on a patch to that one. And then the pipeline will actually wait for that one to land and pre-merge test them together in one test. That's a really cool feature that we love. Another thing is some of these are just not open source. We love open source. A lot of our clients do as well. So we want to make sure that people can deploy their own if they want to. And there are also security concerns. Jenkins. So why would you want some of these features? Well, I just went through most of that. But essentially, gaited merging was the biggest thing is that people always felt that the master branch was working. At least it passed some test. Maybe there's some small degree of differentiation between how you use it and how the master tests run. But having a high degree of confidence in the master branch actually matters. So that combined with high code velocity from that, because it turns out if you start with bad code, you can't finish until someone fixed their bad code, which extends your velocity, makes everybody slow down, and increases people's diversion. Because now it's like, oh, now the tests are broken. I'll go work on a different patch. And a different patch, well, then everything's broken until that's fixed. Versus if you're gaited, it's only broken for the guy who broke it. So what does Bonnie see I do right now? You can manually sign up if you are really, really super crazy brave and you want to try testing your code with our super alpha beta, we're going to call it closed beta, service. It will run checks on your GitHub pull requests. It will run gait tests and merge things into your protected GitHub branches without any interaction from you, which is actually really cool when you start to get really busy. And you have one reviewer who can approve patches and 10 people who can submit them. It's really nice for that one reviewer to go ahead and just go approve, approve, approve, approve, approve, and those things merge sanely, and they all get tested. It can do that for you. And we do have a basic in repo test thing, but we really hate it because we're actually working on something really cool, which is the next version of Zool. So that's part of our roadmap. The roadmap for Bonnie see I is we do want to have an automated signup of some kind so that you don't have to submit a patch to a YAML file to us or talk to us, which is how most people get signed up now. We also want to have more parallelism. Right now we run an untidy little Bluemix private cloud. We'd love to be able to run against different public clouds, different open set clouds. We just don't have the resources. We will have a full in repo job definition language. So you can say run the Python tests, run the PEP 8 tests, run the C module build tests expressed currently fully in your repo because right now you have to express it in one of our repos pointing back to yours, which is not cool. And if you see the two stars, that's because Zool V3 actually adds that as a feature. So we are contributing quite a bit to V3's development. We're hoping it'll be done soon. Across repo testing, we don't actually have that right now, the GitHub driver that we're using, which was submitted by a company called Good Data. Didn't support that, so we don't yet. But we will eventually have that once V3 is done and has GitHub support. And we also want to have true multi-tenancy right now. Everybody's just kind of in one big lump. And so you're going to see that the patch is testing from your competitors. So if you're Coke, you're going to see Pepsi's tests. Yes, I am shooting for the sky, right? So where's that at? Roadmap Blocker, Zool V3. It is a massive effort. It is a huge effort, actually. And it's adding, in addition to the other things that I talked about, it's shrinking the services, making Zool a little more sane to deploy. It's making it more private cloud friendly. There's some problems with Zool that make it hard to deploy when you have a private cloud. That's not, say, reachable from where you run your Zool. As I mentioned, it's doing in repo job definition. And there's some things that have already made drivers easier to write. So I put the red box there, like any upstream project. Timeline's hard to predict. But we feel like June seems likely for sort of pre-release usability. We're not sure, but we're hoping for that. So I think I have maybe 60 seconds for questions. So questions, go. Fast. Yes. These slides are not currently available online, but I am converting them to Reveal.js. And they will be on bonnieci.org in a couple weeks. Got time for one more? All right, thank you so much for listening for my very fast talking. Have a nice day.