 Hello, folks. Welcome to day three of the CoreOS virtual face-to-face. This session is making Fedora, CoreOS an official edition. I'll set some ground rules and then pass it off to Clement, who will lead the discussion. This is a virtual face-to-face, so if you feel comfortable, please turn your camera on so we can see your beautiful faces. Please use the raise hand ability of Google Meet to queue up your question or your response. And finally, because there are a number of faces here from Red Hat and elsewhere, please provide a short introduction. If you speak for the first time, that would be very helpful. Without further ado, Clement, take it away. Thank you, Micah. I'll start by introducing myself. I'm Clement Verna. I'm currently a manager with the CoreOS team. I've been contributing to Fedora for, I don't know, four or five years now. And I'm the owner of the change proposal to actually make Fedora CoreOS an official edition. So a bit of background. So during the Fedora 34 change cycle, we proposed to actually promote Fedora CoreOS as an edition. And we received some quite good feedbacks. This session is pretty much the opportunity to go together through those feedbacks and try to see how we address them and how we can improve our change proposal. And pretty much see the way forward with it. In the ICMD that has been shared in the documents, I tried to summarize some of the feedback and also some of the key concepts that I think we care about. And I would like this session to be very open discussion and kind of like almost brainstorming. So I don't intend to do all the talking, even though it's hard for me sometimes to listen. So yeah, feel free to participate and to share your opinions. Every opinion is welcome. We are all respectful of everyone's opinion and everyone is valued. So please participate. So some of the key concepts that I think we really care about. And probably the main one that caused a bit of discussion is that I think we care that we don't really want to be a Fedora CoreOS 33 or Fedora CoreOS 34. Fedora CoreOS is as its own really cycle and we have like those concepts of streams with our next testing and stable stream. And for the end user, really the base of Fedora CoreOS on which base of Fedora version is based Fedora CoreOS shouldn't really matter. Ideally I think in the change proposal, I think we want to adapt to the Fedora process and how we integrate and we interact with the wider community. But I don't think we want to be tight and we want to be restricted by like really fitting within these like six months releases and having like Fedora CoreOS 34 release announcement or things like that. Do we have an agreement there or is it like something that I've pretty much is something that I thought was like something key, but I might be wrong. So is it something that we feel we pretty much aligned on no objection. I have no objection. I have two comments. One is this is one of the things I talked about like I proposed at like the flock in Prague like seven years ago or something so I'm glad to see that we're finally at the point where we can actually tackle doing it. So you know, slow progress towards the future. We eventually get good places. One thing I think that needs to be worked out with that is how the we don't have releases works with the release blocker progress process because release blockers are one of the few big hammers we have for serious bugs in all of Fedora. And so if if you know generally one of the things we've said around additions are those are the ones where we take blockers most seriously and that's one of the important things about being an addition. If this addition isn't on the cadence. What do we do with blockers there do we if there's a blocker in Fedora CoreOS do we not ship the other things until it's fixed. Or do we say okay we're just not going to rebase onto that new underlying thing until then I don't I don't know the answers but we need an answer to it. Yeah, that was I had one point on that. So I think we can we can dig into deeper into that Benjamin you want you wanted to to comment on that. Yeah, up to this point anyway that's been part of the reason that we have tended to ship the stable release the rebase the stable release a little bit later than the other Fedora additions. So you know there's a bit of a chicken and egg question but what we generally do if we find some last minute blocker for Fedora CoreOS is we'll just hold stable. That may not be the desirable outcome in all cases I think it's useful to have some access to that lever to get packages fixed in Fedora as a whole. But it's also not strictly necessary like if there's some blocker that only affects the Fedora CoreOS addition and not the others. It may not be the right thing to hold everybody else. I'm in favor of that we just may need to develop some new levers that's the other topic that is going on this is publicity because it tends to be that journalists expect us to tell them what's going on in Fedora in our release announcements. We can still do that, but that dilutes the message of there's not there's one stream and not different releases of it because people are still going to secretly think of it as Fedora CoreOS 34 if we emphasize it in the release announcements all the time. So, again, I don't we don't need to delve into that topic right now but we need to figure out a way to do publicity in a separate way. I think next person that was Ben, I think you always do. Hi, I'm Ben Cotton, the Fedora program manager. I want to build on what Matthew said a little bit and in terms of holding the stable release a little bit behind the main Fedora Linux release. I think that also presents a problem when people, you know, on release day, go to try Fedora CoreOS and they're like, wait, why is everything the older versions of stuff. And, you know, the addition, the addition process is as much a, for lack of a better word, political determination as it is a technical one. And so, you know, that's where a lot of these process misalignments are coming to a head where they weren't an issue before. Corina, you want to go next? Yeah, I think there's a lot of like interesting potential technical process. To me, this feels more like an intent, like we will solve these things over time. Like, it's not that we have all the answers right now, but just that, yeah, we believe we can address those sort of things and sort of intend to do it. Because, you know, this tension actually comes up in other cases. Like, I saw Ubuntu actually very recently switched to doing stage rollouts for apt 2 because, you know, like they see the benefit, right? And so, like, you get these sort of like crossovers. So, like, Ubuntu recently, it basically has that same problem. But, like, if you type app update on one system, I mean, I do the same thing as another, right? And, yeah, it's just, it's part of this switching to this world, right? And Simone Tau? So, one thing from the keyway side of things that Matthew already mentioned, we have something called a blocker bug meeting where we kind of discuss, you know, whatever it is. Whatever the blockers are. And then, you know, just before every Monday. Now, technically, we file and maintain all those blocker bug review process as synchronously on a blocker review app that we maintain. But, most of the cool stuff are filed on GitHub. So, there is not much. How do I put? There's not much link between what's there on GitHub, should we replicate those on Pugger and is it possible by which we can have those, you know, kind of cater to while we do the release blocker meeting, rather than having them come at a very late time and then be like, oh, yeah, this was not discussed before. Yeah, I think it's. So I guess to try to summarize and we pretty much have to, like, my feeling is that we have to come up with, like, our own process, but also in some places, like, for example, the blocker bugs. Also, in all, like, the publicity and marketing, like, see how we integrate with other teams within the community and, like, having those bi-weekly releases. How does, how do we, how are we doing that? So, I had, like, my first point was on, like, development and how we integrate with the federal change proposal process. But I had, like, the go-no-go process and release blocker as a second point. Since we started on the subject, maybe we can go into that topic a little bit more. Benjamin, you wanted to. Yeah, just to provide a little bit of context. Oh, I did introduce myself. Benjamin Gilbert. I've, I was very heavily involved in Fedora CoreOS in the early days. I'm less so now when I'm still around working on Ignition and Chorus and so on and things. The reason I think that we're so hesitant to commit to rebasing Stable at any given point is that we have the additional burden of, like, of automatic updates. Fedora CoreOS in particular, so this is just for context for anyone who doesn't know. Fedora CoreOS in particular, we try very hard to never have users have to go manually fix up something. The machine automatically updates. It's sort of an appliance. You don't have to think about it. And if we push out an update that breaks somebody, the concern is that that motivates users to turn off automatic updates and they're not getting their security fixes. So a lot of the decisions around the stream architecture and some of the things we're doing differently are driven by that goal. I think we're much more conservative in terms of updates and what changes also in the OS compared to maybe over-edition like workstation. All right, on the... That's good to let people know because that helps people's confidence in the whole thing. I think this can be a selling point that this is actively managed. Timothy? Hi, so I'm Timothy. I work on the CoreOS team. I think this is linked to the way we do changes because the major difference between Fedora CoreOS and Classic Fedora is that we push changes on a regular basis and we don't go through the same process of having changes be prepared and submitted for review for each release because we don't block them on being in a specific release. So in a way that the release currency is also linked to the fact that we do changes differently and that's something we have to reconcile somehow with the way Fedora does... Classic, I would say Fedora does changes. Yeah, I'm looking at you, Ben. Cotton. I have no answers for that easily. All right. A lot of it is that Fedora CoreOS happens sort of independently of what we typically think of as Fedora and it's partly a question of how much do we want to change that versus how much do we want to keep lending the Fedora name to Fedora CoreOS and have it continue to be essentially an independent tangentially related project. Yeah, I would like to see it. I think having changed proposals going in and mostly they will be self-contained proposals so they don't really need anything. It's not like we're adding another level of approval that needs to happen to these but they go through and people see that this is a thing that's going on in mainstream Fedora activity. I think that'll be pretty valuable and it also helps build the community referencing back to last call. So I think it's a good thing to do that. Maybe we just need a way to tag them as something other than tied to a release. Just call them Fedora CoreOS changes or I don't know, yeah, Ben doesn't like that but let's see that's why I'm looking at you for answers here. Yeah, to be clear the only reason I don't like it is because it very much changes everything we currently have. Not necessarily that it's the wrong thing, it's just a lot of work to re-engineer processes to handle a new paradigm. Jeff? So I'll try and throw this out there. I have people who I recognize upstream would like to replace Docker with Podman, for instance and have no Docker shift on Fedora CoreOS. Is that something that I suggest to Fedora in general? Is that something I suggest just to the CoreOS folks? Is that something that only happens on GitHub? What would be the process for doing something equivalent to a Fedora change request in Fedora but specifically just targeted at CoreOS? Yeah, this hammers on what we were just asking, Ben. So my instinct for that is that is a great thing that would be a self-contained change. If Workstation were saying we're going to do the same thing, we would ask them to do that as a self-contained change and it's a self-contained change because we're not saying we're going to drop Moby or whatever from the repositories. That would be a big deal. But if we're saying this addition is going to ship with Podman instead, that's something that would be a self-contained change and it would be mostly for the stakeholders of that addition to discuss and then for that to be a publicity because users need to be aware. So I think that's probably the right thing to funnel it through whatever it is. And I think having it look like the existing process is... I think having it part of being part of the existing process is desirable. I don't know if anybody disagrees with me on that. I'd like to hear it. One thing we discussed yesterday on documentation and was also to try to... And I think the state discussed it also, having better release notes and things like that. So I see value in taking part of the change proposal process into the terms where it gives us some content to talk about and say, oh yeah, look at what changed in the last month or the last release also. It's just really how we adapt the fast pace of Fedora-Caro is to... And those things get picked up by Linux Weekly News and Pharaonix and occasionally bigger journalists as well. So it does help publicize things. Gordon? Yeah, a different meaning brought up with you. It's actually a really good example of something that probably should have been a change. We just wrote a new software from scratch to update the boot loader. It doesn't affect other editions yet. It is intended to also support young-based systems or even deaf-based systems too, eventually. Because the traditional package managers just aren't very good at updating boot loaders. So one thing I've been thinking about is we could try and align the six-month change cycle for some of these things. But the other thing that's a real tension is we wrote this because we wanted to ship it in OpenShift too quickly. In some cases, waiting six months for something to land can be a real problem and others may not. And I don't just don't know how to... I mean, I don't know. This gives you a whole big discussion. But actually, the Rust compiler is a six-week cycle with longer epicycles. But anyways, I'm just bringing that up. I just feel like it is a really good example of... Yeah, boot up is just a really good example of how we track this change, I guess. Benjamin? I think there's value in not stacking up large changes and landing them all at the same time around a rebase. Just from a change management perspective, that way we have fewer fires to fight at any given time. So we could actually plan or know that we have a few changes coming up, but plan those changes for different stream releases. Ben, you wanted to... I just wanted to clarify one thing about the six-month process. So the window between the self-contained change proposal deadline and the GA release is about three months. So it's not like you would put something in and have to wait six months for it to be released. So it is a little smaller than it sounds when we talk about that. So I just wanted to make sure we were all on the same page with that. And so you were saying, Ben, in terms of the process and maybe automation or things like this, it's very tight to the next number of federal releases. Right, because we have milestones around having the change complete a couple weeks before. So it should be in a testable state by Tuesday for the Fedora 34 release on branch day. And then a few weeks after that it should be 100% code complete. And then we have a beta freeze and beta release and then a couple weeks and then a final release. So those are all very much tied around the idea of having schedule milestones, which doesn't quite fit. So they're like at a high level, the process really makes sense to just bring into. But then when you start getting into the details, it's when it starts getting really... You start getting a lot of the disconnects there. Christian? So I actually wanted to throw this in earlier, but my system crashed. So somebody probably mentioned Cgroups v1 versus v2. That's one of the things we haven't implemented that was a change proposal or a change proposal at the time. I think we're only going to be doing that with the next release, major release. So those are the kinds of things, especially in the email thread on the change proposal. It even came up to just the idea, do we even need the server addition anymore if CoroS becomes a real addition? And I think it's important to note that we still have some areas that are covered better by the server version, at least in my opinion. So for example, we don't have a great firewall story for configuring the firewall in Fedora CoroS yet. Because we don't ship Python, we don't have the firewall command. We don't have support for RPM modules currently. I'm not sure there was a blocker for that in terms that the LibDNF didn't provide a C API for it. I think they've now changed that. So maybe it's feasible that we actually get that soon. But there's just a few things that aren't really tested on Fedora CoroS as a standalone thing. I don't think, or at least I don't know if anybody frequently tests running cockpit on it. So these are the kinds of areas of friction I see in addition to the changes that we haven't been catching up with. I just wanted to throw that in here, that there's still some work to do. Obviously, I'd love for Fedora CoroS to become a full-blown addition as soon as possible. This goes to the politics of additions as well. I think we had on the develop list, we basically, the Fedora server addition had kind of fallen out of attention of anybody. And we were kind of thinking that without that amount of attention, it should be de-additioned. And the surprising result of saying that is suddenly it's got a lot of attention right now. We'll see if that lasts, but they're actually, they're people working on it again. And a lot of non-Red Hat community people with enthusiasm for it, which is great. Yeah, so Colin's comment, we don't want to change the addition status to the server addition status. I think that's true. But we also want to have a crisp, part of the point of additions is when you go to get Fedora, you should easily see, oh, I'm going to do this, I want this one. And so we want to have a crisp definition that can, there needs to be a 30-second explanation of whether someone should go to Fedora CoroS or Fedora server when they look at Fedora. And so again, we don't need to come up with that right now, but that should be part of this process here. And it's part of the reason we don't have like a KDE desktop addition, because we use a different desktop technology is not the kind of thing we're looking for here. It should be use case, what are you trying to do? What kind of user are you? Kind of focus things. So yeah, this is going to sit beside Fedora server at least for a while. And so it should make sense doing that. Which also means it doesn't have to solve all the same problems that Fedora server does. Like if modularity isn't a thing we care about, awesome. That's good for us. All right. So I think to maybe close the topic around like change. And I think we can maybe summarize in like we Fedora CoroS wants to participate in the change proposal. And it would be beneficial I think for everyone in the community. So there's probably a bit more discussion and trying to find a good middle ground and to how we can do that. Is that something we can discuss further with you, Ben? I would like to take it a step further unless Ben tries to kill me when I say this, which is I think we should develop a async change process that sits either within or next to the regular change process and use this as a way to pilot it. And I think we should explicitly say that we want that. Okay, I was trying to be a bit more. I'm trying to nod to you. Let's do it. Ben is making skeptical faces, but not daggers. Right. Awesome. Perfect. I'm glad you wore the shirt. All right. So I think it's worth spending a bit of time also on the release criteria and release brokers and go no go and how that looks like for us in Fedora CoroS. Anyone wants to maybe give a kind of status of what we currently do there? Oh, I can do it. Okay. My feeling is that we currently mostly rely. So as Simon was saying, we have like this Github issue tracker where users can raise bugs and say, yeah, this is broken. So I guess maybe the first thing to talk about is like the relationship between the streams. I think that's really key to our release criteria or go no go process would look like. It's like the relationship between the next testing and stable stream and how they work together. So we expect users to try the next version of Fedora CoroS and report anything that would be a potential blocker or potential issue. And if we have like, if we experience some issues in, for example, in the next stream, that would block this stream from being promoted to the testing stream. If there are like serious issue in the testing stream, that would block that content to be promoted to the stable stream. I think that's currently the kind of process we have in place to make sure that the stable stream is really stable and that we don't break users' content. And I don't know if we have like a formal process where we actually review this. I think it's more, maybe during the weekly IRC community meeting, there are some discussions on that. Christian, you want to go ahead? Yeah, I kind of wanted to focus a little bit on the relationship between our Fedora change proposal process and the CoroS enhancements repository that we have. So I think in terms of process, it would be great if we looked at our, as the Fedora CoroS team, if we looked at our enhancement repository and the enhancement and those that also affect upstream Fedora, we should then upstream as in those enhancement proposals should become a Fedora change proposal so they, you know, so we don't have divergence there. And then likewise, the other way around, there should be some process in making sure that change proposals in Fedora are also reviewed, or at least they're on the radar of the CoroS team. So we don't, and probably we could have probably done better with this because some of those changes we kind of only noticed rather late and then we didn't implement them because, yeah, because of that rolling release and updateability thing. So, yeah, I think it would be great to kind of just create a process for these things and obviously make sure that a change proposal for Fedora should also be valid if applicable for Fedora CoroS. So we don't have this divergence in the future that we don't catch up with Fedora changes. Thanks, Goli. Lamont, you were talking about bugs initially, right? Do we actually make a conscious decision not to have a Fedora CoroS component in a bug cell? I don't remember this. We did, yeah, and I understand that. I mean, it feels like in 90% of the cases, we'll have an RPM component that corresponds to that, so we can at least just, you know, like, ignition chips as an RPM and stuff like that, right? And if we hit, you know, a user hits an Azure bug, like you can file against Afterburn and we can roll it up as a blocker bug or something, but we definitely have the issue, right? It's like, we do ship some bits that aren't RPMs, but it feels like we can just pick a random component, maybe RPMs must be used to come against. I don't know, like as far as just bridging, instead of like inventing a GitHub to, like, some process for Fedora, I mean, I don't know, I actually feel very conflicted about this because I find Bugzilla much very productive, but I definitely understand that people want to work with free and open source software websites to use their free and open source software operating system. So, like, at least Bugzilla is finally open source. So, you know, someone wants to use that instead of, you know, kind of, I understand. Yeah, I think we do have some component in Bugzilla, but basically when somebody tries to open an issue there, it directs them to the GitHub issue tracker, but they can still create an issue. And there's a few of us that are, you know, we'll get an email. Yeah, so one thing that is, as you were talking about the relation between multiple streams, which is testing stable and next. So, in the regular release process that we have, we kind of maintain a, I mean, so as to talk about the quality, we kind of maintain a set criteria. So if something breaks, according to that criteria, we kind of call that a blocker. So like, for example, if Rohit doesn't boot, then Rohit is never getting to that branch state where we can pull it off and start testing. That way we maintain some of these criteria into this link. So currently, it will be great to have some of these basic criteria set for multiple streams. So you can have, let's say this testing stream should be able to run a container, a service, people should be able to auto log in. I mean, those are the very basic things you want them to work as a part of that stream. And if they break, then we kind of go ahead and say this thing is not working for some reason. But most of it is anyway covered by CI. So I guess on one end that part is solved. However, if something breaks, because in the last test day, we have been able to list some bugs which locate some of the packages. But here's the thing, you know, not all of them can be caught by CI. Some of them can be picked up from the change set. If something comes up on the enhancement, we can test them on a regular test stream or something. And we can roll them out as a part of blocker processing. This is exactly what it is. Thank you. Jonathan. Hey, I'm Jonathan. I work on CoreOS, Federal CoreOS and Red CoreOS. I just wanted to raise visibility on the... So Climat was talking about the three production streams. We also have development streams and mechanical streams. And what that means basically is streams that are less... I mean, we do pay attention to them, but the goal is to be exposed to problems much early on. So we have a raw high stream now, for example, which tracks through our raw high. And we have actually found bugs already there before branching, which is already huge progress compared to what we had before. But yeah, I do agree. There's still a lot of work to be done there to integrate more with Fedora. And the one link that Benjamin put into the chat there is an example of how we do that when we track the Fedora 34 change proposals and make sure we look over those and make sure whatever is going to affect us, we're aware of it. And if we need to talk to be part of the conversation upstream, then we definitely should do that. I think a big part of the problem is we're just not talking enough on the DEVEL mailing list to be like, oh guys, let's make sure this also works on Fedora CoreOS. Jeff? Sorry, I didn't introduce myself earlier. Jeff Ligon, I'm a manager at Red Hat for the ARCOS CoreOS and containers teams. So this divergence that we're talking about between the process for CoreOS and Fedora, is there any kind of tradeoff that we're talking about in becoming a top level addition where it becomes the CoreOS teams responsibility to maintain that anything that is being considered for a Fedora change request does get reviewed by CoreOS? I heard Matthew earlier mention that it's nice to have a 30 second pitch or something about the use case of this and why it's different as being the feature of being a CoreOS addition. And so I think that's more of a feature than a bug. But I am wondering where the responsibility lies on whether or not something should be considered by CoreOS if that falls on the CoreOS team or in Fedora in general to discuss whether or not it should go towards the CoreOS addition. Are we surrendering some kind of decision making ability for in return for becoming a top level addition? Or are we just making this a top level addition for the consideration and the naming and the celebrity of being at an April footing with other additions, right? So I'd say to answer that yes and no. We generally give additions and non-addition variants some latitude in diverging from sort of what the base is when it makes sense for their use case. It was things like using the BSD kernel instead of the Linux kernel, for example, that might be an issue. But by and large, if there's a good reason why you can't or don't want to do it, we're not generally going to force that in most cases. That said, I think there is some marketing and user experience benefit for CoreOS to be as close to what all the other Fedora variants look like in terms of configuration and package versions, things like that. So it's really sort of a case by case basis. And I don't know to what degree you sort of evaluate each update that comes through now in terms of obviously Fedora CoreOS uses a much smaller overall universe of packages. So I'm guessing you're not looking at each individual update as it comes out and saying, do we want to pluck this yes or no? So I don't really, for the most part, see it being a change for you when you become an addition. I guess this is the short answer. I think Timothy, you were next. I'm sorry, I'm muted. Okay, let's go again. So that's on the topic of release criteria and which change we look at and everything. And I think the release criteria, we have that in CI mostly. So we don't ever ship images that aren't accessible over SSH or don't run whatever. So concurrent containers or things like that. So it's not even an option for us to ship that. It shouldn't be possible. And then the, so do we look at the dates? I'll say yes, we basically look at every single release we ship and try. We say we have big, well, not so much like a long process, but that we have a process to make sure that each update we ship is good. And we try to improve that all the time. So I'm not saying that Fedora isn't tested. But also that Fedora is is more is much, much more tested in terms that we have a restricted package set. So of course we can do that. But we, we spend a lot more time doing that. So it's ends and so on the other side, the for the changes themselves for the bugs, we also have more options when we have, when we have issues and we can, we can like cherry pick or or I would say discuss specific issues with more options and regular Fedora has because we can refuse to ship the version or skip a version or force an update to a new version. That's something Fedora regular Fedora cannot do, sir. It's, it's a bit of a different perspective around what we ship. Okay, I think Benjamin you were next to go. For those who were around during some of the initial discussions a couple of years ago, I think it's worth noting that we have scaled back our ambitions in terms of how finally we're tuning the package set. So for the most part, we are, we're snapshotting Bode stable into testing and then that promotes to the stable channel two weeks later, stable stream. In some cases, mostly with packages we maintain ourselves like ignition releases will lead Bode stable. In some cases where there's a regression of some sort, then we will pin an older version. So packages will trail both Bode stable and will work with the package maintainer to get that bug fixed. So generally packages do not trail stable or not pinned for an extended period of time. A place where we will tend to diverge a little bit more is that we have a pile of post processing that happens. We will drop will modify config files in some cases that are shipped as part of packages will sometimes delete files out of packages. Well, dropping it of course additional config. There's a get repo that has essentially a whole tree of trees of things we're doing to the file system. So there we tend to be somewhat more aggressive but the package set itself is fairly vanilla Bode stable with a bit of an additional lay for the two week promotion timing. All right. So do we want to add anything on that topic. I think so from, from what I look at, I kind of agree with Timothy that we have mostly everything is in CI. I think we could do with maybe having some explicit or at least write down what are the like, like really the few things that we really care. And that we just so that there is a clear, a clear list of our criteria and what we are checking and that's maybe something to do on our side. So yeah, thanks Micah for the reminder. I like a few over stuff. I think we, we touched a bit already how do we coordinate with other teams so dogs marketing translation magazine web and things like that. But can be there's anyone wants to to share opinions on this like how we coordinate with other teams. It might be good to have somebody who checks in with the mind share meetings regularly. And that is all these things listed in the other teams here are our federal mind share teams. So having somebody who goes to the mind share meetings regularly would probably be a good way to make sure that connection happens. I can actually take this out. You know, because I have been a mind share representative by sometime now. I actually know folks who are working in this specific areas and have been contributing for some time. So I might be able to help this. Okay, cool. I think that's a good idea. All right, so I guess the next steps on this is go and and I've been with with trying to get to craft a new, a new change, change process. And gone. I think in general, I was looking through our additions policy and everything is pretty far along on that list. There's not anywhere I see is like a huge gaps. It's because it's a lot of working on details here things I feel pretty positive about this. Also, the other thing is I wore this shirt today and I realized it wasn't on camera, but I wanted to make sure I showed off here before we end the meeting. Yeah, it's appropriate. Yeah, so really, like, I think the next few things is going to try to at least get a draft or at least start the conversation on the change proposal process and how it would look like. I think we can do better also into like the release blocker and risk right there. We have something a bit more explicit and talk with I might reach out to you cement all and like try to to see from the federal QA point of view. What what you would like and how we can help with that. Great. I think we reached the time. So I wanted to thanks everyone for your contribution. I think it was really quite conversation like a lot of good ideas and good exchange. So thank you everyone for participating and joining spending the time with us. Awesome. I'll stop it recording shortly for the Red Hat CoroS team proper. We're going to have the retro in 10 minutes on the other Google Meet URL. So sticker, please make yourself available for that because we'd love to know how to make these virtual Facebook sessions better. So yeah, just to say again thank you all for attending and contributing to the discussion. Have a great day. We'll see you on online I guess. Thanks. Come on for.