 Okay well let's get moving we've got 45 minutes and apparently you're going to get kicked out at the end so I'm just going to give a quick talk on future relage and things that we're doing and things that we would like to see that not necessarily gonna ever happen but things I think would be nice. Optimism. Great Optimism. All right so one of the big things we've spent a lot of time in the last few months working on is Pungie. We've merged, we got a new branch of Pungie that came from the internal Red Hat Compose tools that merged in the old Pungie with some internal tooling. So the big thing we get from that is that we're now instead of having just one or two people trying to keep Pungie working and making the ISOs we get a whole bunch of extra functionality and we get extra people to work on the tooling. It's a little more configurable in the output which for some of the things that we'd like to do is useful. It means that this ideally rel, sentos and fedora will use the same tooling instead of three completely different sets of tooling and wasting resources and manpower on that. We get a lot better logging. I was going to give a quick show of that. I don't know how well this is going to work since. So this is the output of the Pungie logging composed. We get logging for the arches, global logging. But the Pungie logging to date has been completely hidden from the view. Logging matters too much. But it's something that we get. Today the logging happens on a compose box and QA is like, hey, what was this thing? They have to come to me and I have to go and find that with this we get logging where people can actually see it all the time. It spits out some JSON files so that we can write tooling to trigger off automated composers or you can check what was in it. There's a lot of extra functionality that we get. It's also a lot more complex. It does a lot of its stuff in Koji going forward. We're wanting to look at ways where we can do more of the things in Koji that the compose process does. So it makes more transparent. We can see you can go to Koji and say, hey, where was this thing rather than having to dig into other places to find it? It's a very useful thing where we use the old tooling to do alpha and we're hoping we get things to the point where we can switch to using the new tooling for the better release for Dora 23. And we also part of this is we end up making raw hide look like a compose. So our long term plans want to make the compose processes completely automated so that release engineering doesn't have to trigger, start things off. When a build happens, like a Glypsy build or a Neuroniconda build happens, we automatically run a compose and then we can throw it through a test suite and make sure that it works. Want to reuse the process as much as we can, want to do composes all the time. Ideally, we get rid of the nightly, like raw hide and branch compose and we do them on a as needed basis. So that if Anaconda changes every day, we get a new build every day, but if the things in the output don't change, we just don't do anything. You know, it's only when the stuff that goes into the deliverables changes that we actually do it. And ideally, we do it much more frequently. Ideally, it would be every time that a package on the set deliverable changes. I mean, most of that stuff doesn't really change that much. And, you know, there would be a gating so that if there's a compose in process, we're not going to do another one. But once it's done, if there's five things that need, that say that needs a new compose, we do those five things. And we only do, you know, like if the only thing that changes is a known package, we only go and, you know, make the known install tree and the workstation install tree and the workstation live CD. And that's it. We don't make all the other things. We only make the deliverables that have a changed content in it. In order to be able to do some of this. Yeah. How are you going to fix the signing, the terrible, terrible signing that it says to do with that? I mean, we've been working on the auto signer stuff, which is generally more broken than working. But we ideally, we need a way to be able to sign stuff and trust that it, you know, yeah, I mean, we need to define what what does it mean to be for the package to be signed. You know, at the moment, it's the, you know, if the package is signed, we're like saying, this is good, this is from us. Longer term, perhaps, it's just a means to verify that this thing actually came from Fedora. But, you know, like we'd sign the metadata or we would do some other kind of process where you can have a better verification of what, you know, the content is, you know, the real content from us and not something that someone's maliciously, you know, Trojan. I mean, it just means that we would trust the keys a little less that signs the packages rather than, you know, and maybe then we only have a key instead of changing the key every release. And, you know, I mean, the signing infrastructure is pretty horrible, and it breaks frequently. But that's what I was asking about, as opposed to, you know, how we would like someone to start, how we might be signing infrastructure more robust and I mean, no one's working on the signing infrastructure at all. So if anyone wants something unsexy and difficult to work on, we've got a signing server that could do with some love. Yeah, there's, I mean, single is when it was written, it was net, it was right after the incident. And it was a necessary thing. But it's kind of being written and put there and being left alone. It's all single is completely Python code. Researchers and doing a lot of the work. And they want to make sure everything's consistent. We want to enable a framework for supporting different product life cycles. It kind of comes back to the whole ring stuff, you know, today, we don't have a good way to say, you know, we want to support workstation for six months, and we want to support server for 18 months, we just, we have no way to do we can't say, you know, the end of six months, or these things are cut off, you know, we need to have a good way to define the different rings, the different products, the different pieces, you know, part of it comes down to, you know, if we want to automate, you know, and just read, we go, Well, this package in the workstations change, make the workstation things, we need to know what's in that so that the tooling and the processes can run. But, you know, we need to have a way so that we can, you know, like once the workstation product is end of life in six months, we cut off all the git branches so that, you know, I mean, they exist, but you can't, you know, commit to it, you can't do builds for me, you can't try to push updates from that kind of stuff so that you can, we can say, you know, workstation is supported six months, and that's it. But you know, Fedora 23 on and, you know, maybe longer term, we just want to get away from having, you know, like release numbers and do different levels of rolling releases where we have, you know, stable, a ultra stable and development. And, you know, we just kind of promote things at different stages and make, you know, the more stable ones have a lot less churn and a lot, you know, a lot less change. But, you know, like once every six months, we promote a whole bunch of stuff. And, you know, people do it, they update or they get, you know, their package gets says, hey, you've got, you know, there's a big update here and there's, you know, 500 packages and that's it where, you know, we make things a little easier. But, you know, to be able to support like the different rings concepts and you know, like anaconda and the base, like OS, you want that to never be broken. You know, like ideally we get to a point where, you know, like raw height is never broken because we make sure that anytime somebody pushes a pat, a package and update in, you know, if it bumps a surname and say, well, if I see you or something that is part of the instance, I'm not sure if that's part of the install, but if it's part of the, you know, that core group and we detect that the surnames bumped, we then create a side tag and we go off and, you know, trigger builds for everything that builds against that in the side tag and we don't allow it to get merged until nothing's broken. And, you know, that way we can be more sure. I mean, it's going to slow down some things getting in. But it's not really because you when you push something in that's broken, that then means that nothing else is able to work. And, you know, you've got to go and build these things. You can't actually install it and do the updates until everything's built against it anyway. So if we just push off the side and make it easier to have people do those things on the side, or, you know, instead of having the known side tags, you know, they build the first known package that breaks stuff, we put it on the side automatically and create and the automated systems do all that kind of stuff for us. You know, it's something that needs to be set down and, you know, fought through a lot more and come up with a plan and get resources because it's way more than, you know, the relinch team of, you know, which was one is now like four people, it's way more than we can take on. And it's involves a lot more than just, you know, relinch, it needs a lot of QA by and because without automated QA tests that we can trigger doing things on and, you know, pushing out things only when they've passed the QA tests, we can't do it. So, you know, we need to work with QA and get a consistent, cohesive plan as a project to ensure that, you know, things can run smoother and faster. I mean, ideally, I'd like to push updates when they come out, you know, when you go to Boda and you say, you know, push this to stable, it goes out automatically, it runs a bunch of tests and make sure that, you know, some sanity checking that nothing's broken, but then pushes it out. And it's pretty transparent. Ideally, we push a lot less updates than we do today, because I think we push way way too many updates. I mean, by the time Fedora 20 got towards the end of live, I think the Fedora 20 updates repo was somewhere in the vicinity of about 10 gig. It was quite, you know, 20 was a little bit interesting, because 21 had such a long cycle. Right. So 20 ended up saying 20 18 months. I mean, 19 and 20 ended up being supported for about 19 months, as opposed to 13. But even I mean, 21 to that today is pretty large. And the process for us to push updates takes about eight to 10 hours. We just don't have a good way to get things out quickly. We need to sit down and, you know, re look at that. I want to integrate secondary arches better. So I've said for a long time, I want, you know, when we do a compose, I want to do the compose for the secondary arches. I think the best way for us to do that is probably to bring the building of the secondary arches into the primary Koji. And I mean, my initial thought was to keep it the Kojis as it is and, you know, write part tooling and stuff to just go off and do the things on the different arches. But now after talking with Peter and some other people, I think the best option is bring the building of everything in and use the tooling as part of like, defining that, you know, this is and kind of makes a lot more sense with the 686 talk of having, you know, some parts of 32 bit x86 no longer being primary. If we have the tooling that defines, you know, in our thing that defines what is, you know, Fedora and what's in the different pieces, we can then say workstation x86 64 is primary. And that's it. So that, you know, we're gonna have AR 64, maybe PPC exit, you know, the concept being where going to uncouple the concept of Koji being and where the Koji exists from whether it's a primary architect or not. So and then demote a addition. So you could maybe promote IOT on 32 bit to primary. And you can demote 32 bit x86 server to secondary. Right. And because you're basically uncoupling the concept of Koji and the builds versus a primary. Then the tooling that creates Fedora, it's the thing that, you know, what defines is what's primary and what's secondary is where do we ship it? Do we, you know, do we push it to old stage? Do we push it to you know, Fedora secondary? Do we push it to the main Fedora, you know, repo? What you know, the thing that then would define it is, you know, the tooling puts the things into the different places and how we ship it is what defines what's primary and secondary. Or even, I'll say, it's more policy defines primary and secondary. And the tooling such as Koji and the release engineering process is adjusted to do that. And basically, the difference then is, you know, whether it goes to this area or whether it's promoted on the website or not, as opposed to, you know, at the moment, things have been dictated by, but things have been dictated by tools now that shouldn't be dictated by tools that should be dictated by. We don't have a lot of flexibility and a lot of the things that we've done, because we wrote the tooling and we started doing the, you know, write the processes when we did for course, Fedora seven. And we're using that same tooling, same processes, and when we've folded things on, and it's, you know, time we kind of just sit back and go, we need to reevaluate how we do this because longer term, it's just not working. Yeah. Every actually support needs to have room zero building and working way. And the, and everything else just the thing that I found in the five or so years that I've dealt with, like 986 Arches in Fedora, there's been a number of times where we've discovered tool chain issues on 986 Arches that are in fact fairly major problems on 986 as well. And we often go to find out about them until later on because the secondary is by definition, like, and so at the core, like the Fedora core central bit is ultimately having the secondary Arches in there, or the 986 Arches in there actually will provide or does provide value to the 86 Arches as well. There are things even just like 86 where we can do with some subdivision for the next set. And the work that was just kicked off last week for trying to bring down the dependency set for a very low and smaller update, which is not formally defined. But we always have the problems with them. Every two of the year we have an effort like that. And it only goes over time. And there's no formal way of doing things, right? What we expect to be in the world. You've sort of worked through the three years in Fedora, it is something that I am dealing with constantly. And, but it is something I'm dealing with on a release to release. Very ad hoc now, where we're sitting there basically buying whack-a-mole. And there's nothing great, so it looks like we went another time to get to know that there's no small module, right? Which there are other things that break when it explodes. Because like the Fedora arm minimal build with shrunk it down to enough that basically if something explodes, it starts to fail because it doesn't fit in the allocation space we have for it yet. But it's fairly ad hoc. And it's not me, you know, today when we do like the branch or the war height compose, we get we run repo diff, which says these are the packages that changed. And this is their size. But it doesn't consider, you know, this package added five or 10 dependencies or whatever. And we get broken dependencies. Well, ideally, we don't ever have broken dependencies to get out to the real world. And, you know, if if we have the tooling and the processes in place where we know what goes into everything, we can then write tooling or reporting that you know, we can go, you know, between this workstation compose and this workstation compose, these three packages are added. And as part of our, you know, like nightly or automate our compose process, we can, you know, the output part of it can be, you know, these are these are the packages. You know, this is the repo diff between what changed. But in these deliverables, these are the things that changed in that, you know, so you can see real easily, that, you know, somebody, you know, changed glib, which added dependencies on a whole stack of Perl. This addition, some way out, 300 packages. Yeah. The, the, the Koshai CI stuff, at least as far as I know, it's mostly trying to preemptively detect fast build from source. So when, you know, GCC changes, it rebuilds everything that built the user GCC. It addresses some of the issues, but it doesn't address all of the issues. I know there's discussion about, like bringing those ideas. Like, I know in the enterprise product, I discovered a bunch of failures of all stuff, just before the last four, well, fairly close to beta of the last four is going out. And there's stuff like that, like, we should have been hitting at the point of which it built. So that, you know, the developers are aware of it. And that's exactly the same with the Nora. This is a couple of years ago, I was here talking about being I mean, there's, there's QHS that we can get, but this is the thing now, the knowledge of the software is out there and yet and completely open, but the knowledge of how to use it effectively, although locked up well, yeah, so we've been ready to have it, but how do you use it from? Yeah, but I mean, even if it's a firewall, we don't have a lot of effective communication around. So they have some channel or the X, Y set, because every time I just go, usually, I sort of have the other issues aside, but but this is this is the thing that we've just done. And then we need folks doing the usability work to say, what's preventing people from getting started with it? How do we smooth that all around? How do we, how do we ease people into using it because of the very advanced capabilities, but people are hitting the front end of it and bouncing off. Yeah, and going and reinventing it that way. Yeah. We're going to re deciding though, this isn't more bright and rather than figuring it out, just reinventing something. But this QA test that we could run as early as when you commit, as soon as you commit start, especially if you're pushing your table to look aside cash, we should unpack the table and run a license check on it and see if any licenses have changed. And, you know, there's a lot of QA stuff that we should be doing that we don't, because we just have never done it. I mean, there are only so many of us working on test automation, but people want to help I am more than happy to get some of that stuff working, but we're already busy just trying to get the structure up. I mean, even some of the Tosca Tron stuff that gets around once you create an update, that's almost too late for that is not limited to just when the updates created runs off of that message. The whole design of it is, hey, you made it, you did something to look aside cash. Yeah, those kind of things. It is just running stuff on code you built and updates right now, but it's not limited to that. The only reason it's only doing that is because we have only so much bandwidth to write the actual test. Sure. Yeah, but I mean, generally, to read that, there's a bunch of other people looking at the commit stuff and things like that. But that's happening in the open, which is a lot of cases, we're not even aware that they're doing that. I'm hearing you. There's a lot of good ideas. And as you said, you have four people in reality, we have, you know, I don't know, three people who do any working on test automation or whatever. This is way more stuff than we can do in the next month. Someone sat down and figured out like a complete roadmap with priorities and said, these are the three things we're going to do in the next few months. Or do we just have this vehicle with good intentions? No, for the Royal Alliance, we have a bunch of very defined things that we're trying to do. And the other people can look at it. Yeah, yeah. Where? Where do you find it? Yeah, we're using Tiger. We're using Tiger to do product management. And we have like daily scrums and so that's five different places. No, it's all the same thing. It's one place. It's one place where, you know, we're, we're trying to be much more transparent and better about what with, you know, what we're doing. And, you know, I mean, it's a lot of change. We're pulling some of the people that have only ever worked inside of Red Hat into doing stuff, because they use the tooling internally, you know, the guys that work on the Pungie code internally, we're pulling them into doing stuff in Fedora, because, you know, Fedora and Rella are now going to be using the same tools to be creating the OS. I was just looking at your project would be hang out and I would see meetings and then read the OS. It doesn't say anything about your scrum. Right. Yeah, the wiki hasn't been updated. The all the scrum stuff started in the last six weeks. And the wiki page is probably like two years out of since it's been edited. Any person who read the wiki said they're going to be able to do it for you. I think we said for a lot of wiki news. Going back to what Adam said about the, you know, the good ideas and the reality around, I think there needs to be some significant policy changes in Fedora around updates. It's mentioned it takes eight hours to push an update. And that's really important. That is just most of it's stuff running in the background. But it's what the updates fire. The updates firehose is crazy. Yeah. And it's never slowed down. Ever since we merged for it's been that way. So has that ever been discussed? It has. And you there's a lot of people with a lot of opinions about very strong. Well, I would say, I would say, you know, obviously a lot of Shack of Chantiers use the updates model to push things on their own schedule. Right. But with things like proper and stuff, they can do that on their own. You can say, well, updates are going to be security and critical and inherent. I yeah. I think no, I think a big, big way to change that is to change raw hide. If we can make raw hide to the point where, you know, I think we'll have to rebrand raw hide in the process because raw hide has this conversation that it kills babies, it kills kittens, it does, you know, right. But so I think that like by I think it's part of it will need to rebrand raw hide to something else so that it kind of yeah. But making sure that at least the core part is never broken. And the outer rings, you know, we may go, you know, stuff that's in service, stuff that's in workstation, stuff that's in cloud, and stuff that's in the core ring, it can never be broken. If it's broke, you know, if your update breaks out, then it's going to get pushed onto the side and we have to have a policy engine that deals with what we do based on that, you know, the leaf stuff, if it breaks, it breaks whatever. But by making that core really solid and stable and ensuring that it never breaks. Ideally, that then, you know, will give the incentive to the developers that that's where they want to be. So then they push their stuff only to the only to the, you know, the development branch. And that's where, you know, that's where they stay all the time is in the development branch. And the stable stuff, then by nature, you know, the developers not being the ones using it, but then users being the ones that use it. It's likely to only get bug fixes and security fixes. So I agree with that. I don't know that it's, you know, like a perfect answer. But well, no, no, I think, I think that's, that's definitely what we should be striving for. And really, over the past time or many years, I think that's what our update system has organically, you know, known into you is that it's basically raw. The concept of the unstable and stable branches, and you guys have to reach much more to keep that yellow. So if we can get people to shift over to the other one, I think if we put enough, you know, automated stuff around it, where you know, people don't go, oh, it's a, you know, it's a block of, you know, every time I push something, it gets pushed off the side and I have to go do, you know, if we make things too hard, people are just gonna complain and push back. And it has to work and it has to be quick. And it has to not get in people's world. But if we can do that, then I think that, you know, that'll be the place where people should be. And I think there's, there's so much inbuilt negative connotation with the name of raw hide that, you know, as part of doing that, I mean, maybe we keep raw hide where we just keep shoving stuff and we kind of ignore it. You know, I mean, Susan kind of did the same thing. They, I think it is tumbleweed, the, the, you know, fairly stable, they run a bunch of water, you know, they do the, they do like four or five composes a day, when I was talking to them. And they run it through what OQA, and it's only once they've installed it, you know, run through their test of install suite stuff that they then make that available. And that's, you know, slight delay in that, but it means it's a better, you know, but they still have the factory where they just shove all this stuff in, you can use it if you want, but Well, I mean, that model works well. And there's, you know, similar, similar sort of concept with the nightly No. The problem with doing that at the release level is that there's something great and you then have to fix it. You have no release for two weeks while that one can be fixed. Unless you have to be able to go back to the actual level, then, okay, you've got to go back to the rest of the release. And so yeah, I mean, the thing would be that, like, once the build's done, it needs to run some suite of tests, you know, like check surnames, you know, if a surname bump happens way down low in the chain, you want to push that off to the side and get everything built against it and not push it in until it's done. So in theory, you're always going to have something out there. And it's going to happen frequently because stuff is changing. But you, you know, there may be things in the pipeline that are happening on the side that as they, you know, at least unbreak stuff, it can then come in. So the, what would be, you know, raw hide or whatever, you know, replaces raw hide would be this stable thing that's least the core part of it is never broken. And, you know, if someone pushes a change that breaks that core part of it, it gets pushed off to the side where, you know, it can be dealt with. And once it's dealt with, it can then come in. But not until it's been dealt with properly. So we don't just shove the stuff in and go, Oh, crap, this broke the world. And then we get into a situation where, you know, anaconda can be, you know, we can't create an installer for three weeks, because the package set that gets installed in for the anaconda runtime doesn't depth off, which happens. I mean, it's not just DNF. But yeah, I mean, it happens that, you know, people tend to be overzealous with what they push, and they don't necessarily realize that, you know, by pushing this thing, it actually affects these, you know, 50 other things that use it because yeah, I mean, I mean, not just anyone would want to be right. There's a whole bunch of projects that should be, you know, doing a whole bunch of CI stuff on their source before they even cut a turbo to push it as an RPM so that they know before they even do that that they've absolutely broken the API. And I mean, if upstream projects, whether they're Red Hat or otherwise aren't doing that, we have a number of other problems that unfortunately relanged can't fix. And, you know, even with, you know, people sending emails to managers to shoot on, you know, relanged, it doesn't help because it's not something that we can fix. It's not flexible. We may have this problem over time when we're comparing dependencies on the other languages, and they have cultures where APIs are simply not stable. If you go to a few projects, it would be very good, yeah. It's not really particularly bad. It's a good thing, but it can be actually. Yeah. And that's not normal. This is not something that cooling itself has been. I mean, the tooling is not going to fix it, but the tooling and the process that detects it. And then you have the have a policy or engine of some description that goes, Well, this is in ring zero, it can never be broken. Let's take it onto the site here. Let's either automatically rebuild things, or send notifications to people that hey, this thing has had its own name bump. So if we did, if we detect as soon as it's built, that it's broken stuff, we can then deal with it before it ever becomes something that's visible to the users. And we can highlight to the developers that this change you just pushed has caused these 50 things to break and deal with it appropriately. So got a bunch of ways to get there. Hopefully Koji 2 will enable us to do a lot more of the composed stuff inside of Koji. But I too, which is going to be deployed next week means that, or next week, I think it's going to deploy better too. It should mean that we have a bit more flexibility with our updates. What? I just wanted to give you a heart attack. And all the work we're doing in Pungy, you know, we need to be able to quickly iterate over everything we need to have like, which I think we're going to go with the product definition center, at least to look at it as a tool that defines what goes into each of the products so that we can keep track of, you know, what goes into composers, what came out of it, we can, you know, get start get implementing the things to give us the ability to implement rings and define what's in each of the different products and be able to support different life cycles and all that kind of stuff. Maybe Docker, I just threw it in that because it's the cool thing. And we need to be willing to fail. Yeah, we need to be willing to fail, we need to try things and then go, you know, this didn't work. Let's take a step back and reevaluate it. Historically, we've not done a good job of that. It's like, we've got to keep this, it's like we're in a big, huge big locomotive, and we're going to keep it moving and we're just going to keep moving. We can't ever stop it. We can't ever take it backwards. And, you know, we need to we can't do that anymore. Yeah. And so it does, you know, like Pungy triggers off like live CD builds appliance, well, it's going to trigger for appliance builds. The Docker, we need, I mean, yeah, we need to have. Right. I mean, so what Pungy is. Pungy. I mean, a lot of the images call out to the factory, a lot of media. Right. The integration is tight. Right. The integration is tight. So yeah, I mean, if, if we have the ability to do each of the things, I mean, we need to make atomic repos, we need to sit back. And I mean, we had this plan when we implemented the atomic stuff. And we make the repos and it's really not working very well, we need to step back, we need to reevaluate how we make the atomic repos, how the how the work is important to other people. Right. I mean, I'm asking about if you can build the things that we don't necessarily need on G, we need to have something that orchestrates. And maybe we don't need bungee longer term. Maybe if we put everything into Koji, and we have, you know, like in PDC, and we have something that's watching and goes, Oh, you know, this thing is just being built and in, you know, in the product definition that says, you know, it's in the work definition, let's go off and make that thing. It may be that we don't necessarily need, you know, punji or what punji is, you know, going forward is not going to look anything like what bungee is today. When you shoot or want to use Koji or whether it's fine as punji, I don't think it makes any difference. Doesn't actually going to be a bunch of code that similar to what it is now, because the outputs are still need to be at the moment. Yeah, what they are now. How do you need a lot of environment specific stuff set up? Yeah, it does. It's a little clunky. Yeah, and I mean, the very similar statement you saw sure you can pick you can pick which pile up completely undocumented code you want to stare at. Yeah, yeah, so I mean, longer term, you know, what punji is and may not look anything like what it does today. And it just may be, you know, the name that's the same I mean, so warhead changes I'd like to make there automatic side tags when like surnames and stuff bump so that we can deal with it have automated build QA so that whenever build is completed, you know, we I mean, ideally, I guess in the ideal world, we tag it, the build when it's completed into like a pending tag, we run a bunch of automated QA, we check surname, we check, you know, like licenses opium diff, you know, all sorts of whatever checks we can think of to run on it. We sign the RPM and it's only once you know, all the QA is passed and signed, it's tagged in. And ideally, that takes no more than, you know, three to five minutes. Because if you start adding a huge delay before that build gets into build routes and stuff, people will, you know, fight against it and complain and try to work around it and not work with us. You know, want to sign the RPMs in raw hide over the years from time to time, people are like, why is why is all hide not signed? And the way everything works today, it's just not possible to really do it. Make, you know, something that we should be turning on, hopefully, before F 23 better is, is more high will look like a release compose, we're going to make the workstation edition install, you know, the network install tree and the live the server deliverables, like all of the things that we make as part of a release compose is going to be right. Yeah. That that should be, you know, we should be making the steps of making that happen. You know, the live CDs will be on the mirrors and you won't have to go to Koji and go, where do I find the task for the last working, you know, workstation live CD and stuff like that. Yeah. And fully implement the ring stuff that Matt's been going on about for a few years now. Well, what does it mean? It means that, you know, we can we still need to define completely what all of that is. But you know, at least from my understanding, like the ring zero would be the minimal installation, and the suffice in the work in the base working group of a minimal installation, anaconda and its dependencies that the core stuff that you need to be able to run an anaconda to do a minimal install yet to be defined. But yeah, but you know, we kind of still need to define that we're out of time. So if anyone has more questions, or he is snorsy, going through the issue, which is great. And I want you to do it. But after that, the next step would be allowing layer products on tops on federal because I'm being working on the infrastructure side. And the problem is that we have very different schedule. We need to write packages. Yep. That's why some products are leaving federal, which is concerning. Yeah. And I want you to do it at some point, we'll be able to say, okay, you won't be federal, but you will be able to base products up on federal. We were using rainings and during, for instance, it's a very cool and maybe maybe it's something to be looked at. I mean, maybe we do it as in Florida and in Koji, or maybe it's done in copper. Doesn't stop. But yeah, I mean, having a way to do that, like support layered image stuff, or layered product stuff in Fedora, it's, it's something that, you know, all right, well, thank you all.