 Our next speaker up is Adam Schummelig, who's going to talk about role development in public. Thank you for the introduction because I have an ability by bio, so that would be embarrassing. Hey, my name is Adam, I work for Red Hat, and I work on the CentOS Stream Engineering team. Just one thing I want to say, I don't represent Red Hat's view, this is my personal view. I have an engineering role, so this has been mostly on that theme. I actually gave some similar talk last time, and last time I showed images like this and that showed the situation between CentOS Stream, that we have Fedora where all the innovation and work happens, and basically that's where the next major enterprise, the next version, gets developed. And then there was a big jump to RHEL, and then a CentOS was rebuilt. And these days we have two more steps. Fedora is still the next major version, and we have now Fedora ELN, which is like a smaller subset with specific build flags to be more representative of what's going to happen. And then we have CentOS Stream, which is role development in public, and that's where the next minor version gets developed. I also had this image, I get more details about where the sources are, about the size, about the build flags and stuff, and this is actually the first change I want to make. I feel like we really need to think about the CentOS Stream and RHEL sources as one thing, because CentOS Stream is where RHEL gets developed in the open, and that affects what contributions are happening in both places and what the goals are. Fedora, as you know, is a community distro, and the goal is to create a community distribution. Fedora community decides about everything that goes in it. RHEL is an enterprise product, and CentOS Stream is the space where it gets developed, so that might influence what gets in there. But the takeaway is basically they have different contribution model. But anyway, this is a community conference. Why am I talking about an enterprise product? I'm here to just set the stage where CentOS Stream is. It's part of the CentOS project, and it's sort of a weird part, because it's basically RHEL. But there's many other things in CentOS project that create a community, like SIGs. We have, for example, the hyperscale SIG that make it work in a big-scale environment, and are actually nice people to talk to, because of KMOT SIG, alternative images SIG, automotive SIG, ISA SIG. There's like many SIGs, and this is where the community is. This is the CentOS project. They usually build above the operating system or do changes within it, but they don't have to reproduce the whole thing. And if you actually want to do work in the OS and do some innovations and integration, that's Fedora project. That's a great place for that, and that's where bigger changes can be done. So also, you may be heard back talking about agency. That's what the CentOS SIGs are, and join a SIG or create one and make your own things. But this talk is about CentOS Stream. So let's have a look at the flow. How things get done, and because my focus is engineering, you'll get a flow chart. So this is basically how every change happens, and I'll walk you through. So first, what happens with every change? There's a bugzilla bug, and there's some projects coming on to switch this to JIRA, but that's for later. So that's where bugs get reported or features get requested, and basically an agreement is made to proceed. Merch request happens that's in GitLab, that's where the code lands in the repo that gets mirrored to the internal infrastructure, and then a build gets submitted in the build system. We have three stages that you can follow the changes through. When a build succeeds, it lands in the gate tag, and I'll show you in the build system how it looks like. Then there's some gating, which are like a bunch of internal automated tests that happen, it gets to the candidate tag, and then there's a verification step, which is really like Red Hat internal paperwork stuff, and then it gets to pending, and can go to a compose. What's a compose? Compose is like a collection of the RPMs, a certain snapshot at a certain time, which are made into a repo, made into images, OS trees, and anything that you can actually consume. And actually, one new thing that's not on the slides is we are building some testing, some release testing. So we take the production, compose, test it, and then that gets released into the mirrors, and we push to mirrors, we push to key oak way for container images, vagrant, AWS, and all that things. And actually, some of the testing, which is something I want to talk about with you later, and we'll be looking for community to contribute tests and define how this works, but we can talk about that. Okay, so let's see how it works. So this is a bugzilla bug. It's an old one, but it just illustrates how it works. That's how it started. There was like one particular change, and you could see that on the URL like that. Then a change landed in GitLab, which is, that's the pull request. And by the way, that's where all the sources are. So if you want to browse all the rails, basically send those stream sources, go to gitlab.com. Slash thread, slash send those streams, slash rpms, and everything is there, like all the comments as it's landing during development. And they land like pull requests like this, and then a build gets submitted. This is Koji, this is the build system, and you can see all the build logs and everything in there. And if you scroll down a little bit, there's the tag. So there's candidate, gate, and pending. So it passed all the steps, and it's ready for compose. Actually, one thing that we just added like last week is a pending signed, and they're just an implementation detail where all the signed packages land to make releasing smoother. And when it gets released, not released, compose, this is the composes.stream.sentos.org. We have the production composes there, so you can get the latest, and there's the repos and some basic images. And after that, it proceeds to the release, to the mirrors, and that's next to the SIG content. And that's where you can get sent those stream, the artifacts. So that was the flow. We basically saw it going from bug, contribution, build, test, verification, compose, and to the release. And with that, let's talk about contributions and how stream relates to rail. And you got a flow chart before now, you get a life cycle diagram like this. This is what rail life cycle looks like. This is a rail nine. I think it's from product pages or somewhere. You can find it online as well. But basically, every minor release, I think this is like half a year each, new one gets released and it gets supported in various ways for various stages. So there's the minor release, there's extended update support for some, and then update services for SAP solutions that's even longer life cycle. So you can see there's a lot of things happening, but for sento stream, you don't really need to worry about it that much. There's arrows that point where sort of sento stream is. So like this whole thing gets developed in sento stream, so it sort of follows along. You don't really get the sense of the minor release. So that's not there. What's important to know, the vast majority of packages in rail and therefore in sento stream never change in ABI throughout the whole life cycle. And there's a document, the rail application compatibility guide that you can Google and read for more details. And Red Hat takes this very seriously because customers build applications on top of rail and they sometimes just want to run it and never change them. So Red Hat doesn't want to break them. Which takes us to the contributions. What you can contribute is bug fixes. They're very easy to do and valuable. If you have a bug fix, you can submit it, of course. Just please don't break what customers have guarantees on and Red Hat needs to decide or the maintainer needs to decide what goes in, so the maintainer needs to test it and merge it. Another type of contribution is stable updates from upstream. That's usually fine. Stable, that's a flexible word, right? This means that it changes in the code base. As rail gets older, because it's ABI stable, the upstream gets way far from it. So packages usually don't rebase. So if there's a stable update from upstream, that's good. But rail doesn't tend to pull in drastic changes that much, of course. Which takes us to back ported feature, which is an interesting thing where you take a feature from a newer version and do a lot of work to make it work in the old version without breaking it. And that's actually how many updates in rail are done. And you're very welcome to, of course, do those too. What we can't do in CentOS Stream is ABI incompatible rebases. That's what I mentioned. So, if you're interested in the rail application compatible as a guide, please don't send those because Red Hat would need to reject them or the maintainer. And then there's a special interesting type about docs and typos and man pages. As I mentioned, there's a lot of process involved with every change. So even like if you change it, you can see that it's bundled as one thing. So these might take longer. Otherwise, if you're a customer, there's a thing in the customer portal that you can report an issue to documentation. So there might be a different channel for that. Okay. So that was about the types of contributions. And I know that contribution that's actually why Fedora is very valuable. And if you can, please do your contributions in Fedora and let it flow into stream rather than making changes in CentOS Stream. Or if you want to change in CentOS Stream, just join a SEG. Or start a SEG and do your change there. That's also very welcome. And yeah. Okay, so how to do changes? Open Box in Baxilla. This is very welcome. If you make it easy for the maintainer to reply or read, that will definitely help. You've seen the life cycle diagram. They have a lot of things to do. And we have like three major releases on the fly. So there's a lot of active releases they need to take care of. But so opening Baxilla, merge requests, please send merge requests. But first, please talk to the developers in a bug and agree with them that they actually have capacity to merge it before. And if that lands, then you can follow it through the pipeline as we've seen and see your changes land in there. And when they make it through completely, they'll be on compositestream.centos.org for you to for you to use. Okay, let's talk about using CentOS Stream. This will be just like two slides. Try Fitches and Development and then we'll talk about bug reports, submit patches before it goes to REL. That's what it's meant for. It's a preview of the next minor version of REL. So that's one use case. Or if you built on top of REL, you can use CentOS Stream as CI. Maybe you will hear about that in a bit as well. And you can make sure that your bits will work on REL in the future. Along with the SIGS built on top of CentOS Stream in that way. And if something breaks, you can always submit a bug or maybe a merge request and get that fixed, which you couldn't with the CentOS Linux before. And that was it. About how it works and now I want to talk about CentOS Stream 10 a little bit, which is coming very soon. And this is a horrible diagram I made. It's supposed to represent code change and like a git change. We have Fedora row hide branch in Fedora. We have Fedora ELN, which is basically the same. It's just a subset. And when some Fedora gets branched, that's where CentOS Stream will start appearing. Actually, we already have some CentOS Stream 10 sources already in the CentOS Stream. Don't take this as a final list of things. I think packages will be appearing, disappearing. It's in a rough state, but you can see them there. And that will be still thinking changes from Fedora for a bit. Then we cut it off and have only CentOS Stream. From that point, ELN will be like row 10, row 11, sorry. And then further in the line we'll start building row and row 10. And then we have CentOS Stream. So if you want to land changes, go to Fedora row hide and land them there. And there's still time to get those. Otherwise, that was mostly it. That was CentOS Stream. Real development in public. Remember that CentOS Stream is just one part of the CentOS project on this invisible slide. It's just one part of the CentOS Stream project. These are the spaces that you can join and contribute. Here are some of the links. That's it from me. Thank you. Any questions? Yeah, Neil. So you put question marks for the Fedora version with that little graph showing CentOS Stream 10. But we're already supposed to do that. Do we know the number actually? Yeah, it's 40. It is, right? Yeah. So why the question? There you go. It's Fedora 40, but there might be some changes. It might be slightly rough. Sure. Thanks for the question. One thing I wanted to clarify when you're showing your row hide and then the branching and all of that process. For ELN, most packages are you're just rebuilding with row flags and there's very little difference. We kind of discourage doing if Fedora, or try not to do that too often. Kernel though, the ELN kernel is the REL 10 CentOS Stream kernel. Even though it's the same disk it, it's built completely different. It is a REL kernel. So if there's something you want to see and you don't have to wait for REL to branch this and then suddenly make changes, it can go into ELN now and you have a working kernel that is a REL kernel. Cheers. Thanks.