 Hi, welcome. First good question. Everybody asks, what is kernel CI and why does it matter? Well, Jim, I guess, started it. But the main thing is kernel CI is a project for testing the kernel, and it's a project that started, what, I guess, six or seven years ago now, mostly among a few kernel maintainers, that we're recognizing that, well, like Jim said, Linux runs everywhere, it runs on so many different pieces of hardware. But the testing on that hardware was very minimal. A lot of people, most people were just testing on the few things that they cared about. So as maintainers, we wanted to test it on as much hardware as we could to make sure that we're actually supporting all the hardware that we claim we're supporting. So that's kind of how it began in the kernel community. So it's just collecting a bunch of hardware and running the kernel on as much of this hardware as possible is kind of where the project began. So that, yeah, we had the maintainers summit for the kernel a couple weeks ago, and one of the big problems that we have now is we have six or seven different projects that are sending kernel developers and maintainers bug reports saying they're doing kernel, they're doing testing, whatnot, and so much so that they find the same problems and we're getting really annoyed. So we came together and said, pick one and do that. And so we've agreed on this one, right? Everybody, all the companies finally agreed we're all going to work together, not do duplicated work. Yeah, so we went from a problem of having not very much testing to in the last two years, maybe we've seen a lot more CI efforts and a lot more testing efforts on the kernel, but they've been kind of fragmented. And so, yeah, we've been a lot of different projects are sending doing different types of testing on different types of hardware. And so, yeah, the idea behind kernel CI is let's collaborate on that stuff. Let's work together. I mean, we have open source software for the kernel, but we're, we don't really, we haven't taken the open source approach to our testing efforts. So kernel CI wants to kind of collect that and let's start sharing our testing software, just like we're sharing the rest of our code. Yeah, because all those other testing efforts were actually closed source. So people weren't opening their tests or the test infrastructure. So people couldn't duplicate it. So we get a bug and we couldn't maintainers couldn't duplicate it whatnot. And now we're finally solving that problem, hopefully we're creating a place that we can hopefully solve that problem where we can share our share more testing and share more infrastructure work. And yeah. And as part of the plumbers conference, you guys all all those different projects got together and had a day and talk. And what did you guys decide? Well, we did. Well, first of all, we just decided that this is a this is the right thing to do. Okay. But I think that the impetus behind that at plumbers, especially, was there was several other discussions at plumbers that were basically around we're finding bugs way quicker than we can actually fix them. So because of these testing efforts and particularly some of the kernel fuzzing efforts, the ability for us to find bugs and and well, yeah, find and track bugs is actually increased outpaced our ability to actually fix them and track them. And so we need to in, you know, not only do better testing, but do better tracking and fixing and making sure that we can actually do these things in the kernel. Yeah, like S Y Z bot has finally started tracking things and they're working with you guys on that, right? That's good. So of all these individual things, so why is it important that we now have a formal governance and founding of a project for it? Well, I think that the governance helps because it gives a place where we can actually share companies are generally reluctant to share. I'm not sure why testing testing software is considered secret sauce, but a lot of companies consider it secret. So or or at least special or something. So having this Linux Foundation project is a is kind of a neutral place where we can share start collaborating on some of that stuff. And hopefully realize pretty quickly that most people are doing the same thing. There's a lot of stuff we can collaborate on, a lot of data that we can share. So I think just having that that neutral place at the Linux Foundation is going to provide that. So we won't create yet another testing. Yeah, I hope we don't create yet another testing framework. Yeah, we probably will. But I hope at least we can do more yelling now. So along those lines, what can we expect? I mean, what is your roadmap for the future? I know you've had wishlist in the past. Now that we have a formal organization and everybody's working together, what can we expect to see? Yeah, so we have actually each of these each of the projects that have been collaborating have a wishlist. So we're getting together and kind of putting our wishlist together. I think while the first thing on the wishlist is to just start sharing our code and sharing our test results and collaborating on kind of the basic infrastructure pieces. But then the probably the the next biggest item on the wishlist is better reporting and better like better visualizing. The several of these projects have been running tests for years and collecting a lot of data. We're not doing anything with that data at the moment. So we've got actually quite a bit of data on the historical testing of the kernel that we could be mining and actually doing some interesting things with. So I think there's collaborating on that, you know, only sending one or two one or two males to you instead of ten, right? That'd be good. Or just send me something that I can understand. That's hard. You get these reports and it's buried way in the middle. We want to send you a happy face or a frowning face and that's it. Some people start using the emojis for checkboxes. That'd be good. And you're okay with that? I'm okay with that. I can handle emojis. Cool. So what else? Anything else? That's just better collaboration and better, I mean, yeah, all the big data stuff. There's actually quite a bit of data we could start mining. So I'm looking forward to bringing some skills outside the kernel community to help us start looking at all this data and doing some analysis. There's probably some pretty interesting trends and stuff we could mine from this historical data as well. So that's another thing on my list. Okay. So it's part of the long-term kernel and the stable kernels I do. KernelCI runs all this stuff all the time. And it's really important to me to make sure that things don't regress and people can rely on this stuff. Is this important or I know you wanted to talk about that? What about that? Yeah, so that's important for a few reasons. One, for you just to be able to help you and Sasha decide when stuff is stable and when it's not stable and to give you kind of a path to what's kind of a baseline for what's a stable kernel. But it's also really helpful for companies that are shipping products on stable kernels. I mean, my company, Bay Libre, we work with a lot of companies shipping Linux products. And when they're looking at like a next generation product, they want to move to the latest kernel and having some sort of kernel testing infrastructure that they can look at and say, okay, we're going to move to the next kernel. And all these tests have already run on that kernel. I think it's like having this database of what stable kernels are already out there, what they've already run, what they're past, what the tests they've been running and so on. I think it's a really good resource for people to rely on to be able to decide what kernel they're going to ship in the next product. And people can take kernelsCI and run it on their internal boards because I know a lot of companies don't like publishing things before hardware comes out, before products come out. And that's a big thing about kernelCI. That's much different from other stuff. Yeah. So kernelCI, we have a service at kernelCI.org that we run for all the community stuff, but all the software behind that service is open source. So you can take it in your inside a company and run it as well on your own hardware if you don't want to share tests. And if you don't want to share the new hardware that's not quite out yet, that type of thing. And then you can flip a switch and start publishing results to the community when the hardware is available or when the things aren't secret anymore. And you can test your three million lines of code you've added to the kernel. Make sure nothing regressed. Well, actually, it's really important because a lot of embedded devices are that way. Most, yeah, a lot of products still have a lot of stuff. It's not upstream. Oh, still out of tree. That's a different... That's a different argument. That's a different chat. Yeah. Anything else you want to talk about? No, I think that covers it, yeah. Okay. How can people get involved? KernelCI.org. It's up there. We have a mailing list. We have IRC. Come talk to me in the hallway. I'm here all week. Yeah, that's it. Great. Well, thank you very much. Thanks. All right.