 Okay, all right, so my name is Paul Frields. For those who don't know me, I see a few faces that I do not recognize, which I'm really happy about because that means new friends to make. Also for those who don't know me, former Fedor project leader, and also I worked on the REL product as well as the development coordinator for REL 7, which means that if you found something wrong in REL 7, I will point you to whoever's fault it was. Definitely wasn't mine. No, I'm just kidding. So nowadays I manage a team of people who work in and around Fedora on platform-related problems. They don't work 100% on Fedora, not all of them, but they spend a lot of time around Fedora and you probably know many or all of them. And so how did I get involved in doing this talk? Basically because Brendan tricked me into it. He has a superpower for that. So we're going to talk a little bit about Lifecycle and this was alluded to in a previous talk. Some of this may be a bit repetitive with that, but again, the idea is to get the concepts I think to sink in. What I'm not going to do is I'm not going to cover a full implementation of how this would work because undoubtedly that is more complex than I could cover here in 50 minutes. It would leave no time for questions and really there's a lot that needs to be figured out by people smarter than me, which is why Josh is here because undoubtedly you guys are going to have questions and if I can't answer when Josh is going to save me, hopefully. Apparently Paul was not paying attention in my earlier presentation where I said, I do not have any answers. In two of us, we have no answers, so we'll see what happens. All right, one second here, let me straighten this out. Okay, so why do we call this talk at long last rings? Well basically because Matthew Miller, the current Fedora project leader some years ago, talked about rings as a way to solve different contributors and different consumers problem sets inside the universe of the things that Fedora builds. So we're going to talk a little bit about that in this talk. What we are not going to do is kind of outlined in this slide what we are and are not going to do. I'm sorry, give me one second, this turns out to be much more difficult to read from over there than I planned. Okay, this is easier. Sorry. So what this talk is and is not, what it is not is it is not a hand-wavy concept that's going to disappear. Now that doesn't mean that you're not going to see some hand-waviness here. You may, it all starts here, but this is not a concept that I think is going to go away because the problems have been floating around long enough that parts of the open-source world and parts of the commercial world already have started to address this. The problems that people had as consumers several years ago still exist and they've been solved by technologies that largely progressed ignoring what Fedora has done to put out our main distribution. And again, I'd allude back to talks that Matthew has done in the past where he talks about those problems, like why distributions may not be as interesting as they used to be. What this talk is though is talking about a plan that Red Hat wants to put effort into and that's why I think it goes part and parcel with some of the other talks that you've heard because it is something that we want to put effort into as community members. This is not about core and extras. Why did I bring that up? Well, you'll see later in the talk there is something where the word core comes up and I want to make sure that people understand that this is not about differing the pieces of kit that we build by who is allowed to work on them. Talk a little bit more about that later. It is about treating packaged life cycles differently, but affecting people equally. So in other words, people will be able to contribute to them equally, will have consumers out there who are able to use them, but the life cycles themselves would differ. And it is not also, this talk is not about defining a minimal image, which frequently is another bike shed that we run into when we talk about problems like this. We're not going to get into defining what that minimal size image means. What goes into an addition, these are all problems that are largely not relevant to this particular talk. But it is about distinguishing between the operating system platform and the many applications and the many kinds of consumers and producers out there who make them. Okay, so a little bit of a history lesson here. So how many people here were around when core and extras were combined? This would have been around Fedora Core 7. Okay, quite a lot, but not everybody. How many people here were involved in Red Hat Linux or Fedora when they were separate, when Fedora was first came around, right? I guess me kind of. I was around at Fedora Core 1. I am old, it happens, Josh, to us all. So here's a little bit of a history lesson. So when Red Hat premiered Fedora, they did it by opening up a package set or package repo called Fedora Core and essentially this kind of open sourced what was going into what was Red Hat Linux 9. That kind of became Fedora Core 1 or what would have been Red Hat Linux 10 became Fedora Core 1. Because who would ever go to a number higher than 9? 10, that's ridiculous. Why would you ever have numbers bigger than that? I don't know. Matthew's up here putting his head in his hands. But still, when Red Hat did this, most of the community members couldn't do anything with those packages. There was a notable repository in those days that Warren Tagami used to run out of, I think it was at the University of Hawaii at the time, which allowed you to basically add packages to your Red Hat Linux distribution to do things that didn't come out of the box. And that really became extras and became Fedora extras. And those packages were really the only place that non-Red Hatters could contribute to Fedora. At Fedora 7, one of the things that then Fedora project leader Max Spivak, who was my predecessor as a project lead, one of his big projects was to bring together core and extras into one Fedora package universe, which has consistently been produced to this day. So that was a really nice thing to have for a few reasons, not the least among them being that all the package requirements were kind of smoothed out. The overall quality of what was being produced went up because we started applying the same rules to all the packages, whether they were built by Red Haters or by volunteers. All in all, a very good thing to have. So I mentioned that this talk was going to reference rings. And right here on the screen, you're going to see Ye Olde Rings proposal. And this is circa 2013. Earlier, I think Matthew showed a slide. I realized that I had missed the revision of this diagram. So you'll see that here. And it's roughly the same. The idea is the same. This one's maybe a little more readable. But it's really about having several different components or several different regions that we treat differently in policy. Rather than really thinking about this on a purely policy standpoint, I think this talk is more about thinking about them in terms of what their lifecycle looks like. But you're going to see a lot of the things here that you would think about when you separate base OS and apps. You still have a base crunchy Nougat core here. And then outside, again, there's that word core. We'll talk to that in a minute. But you're also going to see a lot of the other app stacks that you would expect. So you see there's a lot of doggie doggie doggie. Containers do come into this in a way. Third-party applications, there are different stacks here. You've got additions, all this stuff. And really, what this talk is about is, OK, let's forget about all of these various particles that are sort of orbiting here. Just think of this in a very simple way, which is just, again, this sort of crunchy Nougat core and then this nice fluffy outside, which is our applications. So what do I mean by simplified? Well, for one thing, what we're not proposing here is something like parallel install stacks. Here's how you're going to get them into the distribution. Really, that is a great use for containers. Nowadays, what we've found is that people who are using a stack of, say, Node.js6 versus Node.js8 or someone who's using Python 2 versus Python 3 for their stack, well, maybe less Python because of how it works, but Perl, say, Perl 5 versus Perl 6, are not generally going to be doing that on one system. They're not trying to merge the use cases together. Instead, that's a great case for using containers, where you have a user space that is going to support the stack that you need. You'll build your application on that, and that's how you'll vend it. It also is not about separating out the just enough OS and the platform, which was a feature of the original rings proposal, but instead, again, focusing on the lifecycle. All right, so why do we care about life cycles? Well, I think, again, this was set out earlier, but we push a lot of content into an official release. Thousands of packages, thousands of RPMs go into building what we ship on, say, Fedora Workstation or Fedora Server. You might hear me tend to talk a little bit more about Workstation here. The only reason for that is it's the working group I've been most heavily involved in, and it's typically what I run, but I think you could probably apply any of this to Fedora Server. You could apply it to Fedora Cloud as well. We push a lot of content into those releases. We push that. There are thousands of RPMs that become part of what's ultimately going to go out to consumers, and what that means is we have a huge testing and integration service. The combinatorics for that surface are enormous, and when you're trying to ship something out on a time-based release, that inevitably means that there's going to be a lot of things can escalate to blocking that release when you don't really want them to. And it also means an inordinately large number of people have to be involved in release mechanics whether you like it or not. If your package is part of that release and because of a very long dependency chain, something very high up the stack is causing a problem that then reflects back into that release, then you're going to be dragged into the mechanics of, oh, how do I get this package fixed in time? I need to get an exception. I'm going to be involved in a blocker meeting that I get pulled into, et cetera, et cetera. And all of these happen at the same time. So these thousands of packages are all kind of causing the same problem at the same time. And worse yet, because of the way we run our releases, it means that if you're trying to get a feature out, if it's something that is part of, let's say, that there's a particular feature in GNOME or a particular feature in KDE or something like that, if you miss the boat for the release, then more often than not, it means you're going to have to wait six months to get any publicity around that release, a special, and sometimes you may have to wait just to get your feature included just by didn't have the way that the features work. Of course, we have raw hide, which is kind of a fallback, but the problem is, of course, we only have maybe a few hundred people in the world who are running raw hide day to day. All right, so how do we make these releases? Well, right now we bag up thousands of these RPMs on a single cycle to make a product. And the cutoff for what is allowed to block the platform release is sometimes uncertain because that release is so big, because these dependency chains can sometimes reach up and down the stack. It creates a really large surface where things can break and affect our timeliness. And I think if you were to look back at the number of times that the Fedora release has slipped past its release date, that is many times because of the amount of coordination that's required around all of these different packages. Now, thankfully, we actually hit a release date for the first time in, I think, ever in F28, and that was fantastic. It was a great release, and I think there's a lot of people who deserve great credit for that. However, I think that ought to be more the rule than the exception. Now, so what if we had a different kind of release? So what if our release surface were smaller? I'm not necessarily saying how small, but imagine that it were smaller. It doesn't necessarily mean that we ignore testing. We ignore integration with other pieces. It doesn't mean kind of rolling that release on and let everybody else kind of throw their fate to the winds. We don't really care what happens to them. That's not a very community-friendly way to work. This is not about excluding those folks. Rather, it is about concentrating on a platform that we know we can put out on a fairly regular and routine basis without fear. And right now, I think we fear releases more than we look forward to them. A lot of us do. Now, how do we do this? Well, one of the things that we need to do is we need to increasingly use CI. The reason being is that if we have more dedication to the CI effort, and when I say the CI effort, what I mean is a good set of tests, a good set of integration tests that let us release new packages and new stacks of software with confidence, the confidence that we don't always have right now. So increasingly using CI so that those pieces can move at their own pace and layer on top of the platform. So we'd have more confidence in the platform. We also can have more confidence in these stacks. Now, as luck would have it, there's kind of a ready-made surface coming our way. One way we could look at this is, hey, this is kind of a unique opportunity for us to look at the new Fedora CoreOS project that's out there. Get interested and see if we can build on that. Fedora CoreOS, as you guys know, it's a RPMOS tree-based system, or I guess on the way. And that presents a lot of unique opportunities, right? One of them being that the whole operating system comes out as a piece and it's tested together. If we do our jobs right, we can CI that whole thing together. Hopefully we can automate a lot of that. And because it's smaller, we can create it faster. It's my belief that one of the major problems that we face right now is that the time it takes to create the thing that we call the Fedora OS is extremely long, hours and hours and hours. And if we get it wrong, sometimes we can do another one that day, maybe even a couple more that day, but mainly that happens because of the heroic efforts of people like Mohan. I don't know if Mohan, Mohan's here, great. Mohan basically works his fingers to the bone to make sure that we get releases out on a regular basis. And it pains me to see that he has to work so hard to get that done, especially as we roll down the weeks towards the big release date. It would be wonderful if we were able to create smaller things faster as opposed to a gigantic cornucopia which has to be complete and everything has to be in the right place. The grapes have to be over here, the oranges have to be over here, the bananas have to be here, et cetera, et cetera, in order for that cornucopia to be presented to people instead of maybe just presenting them the thing they really wanted, which was a grapefruit, right? They just wanted that grapefruit in the center. I don't know how well this analogy is working, but. Are you gonna use it from now on? You're welcome to it. So one of the things that we need to be able to do to comfortably achieve this level of automation is we need to be able to spin a whole installable artifact for every change that we make or every change that we propose, not necessarily make, right? And the change that actually gets made is the one that still allows that artifact to be created and to pass a series of tests. Now, right now, the amount of time that it takes for us to create our artifact or artifacts is so large that there's no possible way that we can do this easily, at least not with the artifacts that we're making right now. So one of the ideas I think that we ought to be looking at is slicing that base OS down to a smaller level, something that we could reasonably create on an on-demand basis in maybe just a matter of minutes. Who knows, maybe even less, depending on how it was built. So that's something I feel like we desperately need to address. And I think this is, again, the area where the thing that might scare some of you who've been around a very long time is the idea of the words fedora and core together. And so I just wanna make sure everybody understands, just to be clear, we can't avoid that, those two words being together because that is a thing that exists. But I just wanna make sure everyone is clear on the concept that what this does not mean is protecting a group of packages and not letting community members have input into how it's built, not letting people put in things like pull requests to make changes and improvements. Those things can still continue. So this is really just about being, this is about one possible avenue to build a small, tightly integrated platform, concentrate on that and do it well. Hey, Paul, can I add one thing on the CI aspect of it? Please do. So how many of you that are fedora package maintainers opted into CI when it was up and running? Problem number one. Problem number one. So here's the deal. CI is often talked about as a magical solution to quality, but you only get what you put into it, right? And so it's not only enabling CI on your package, it's making sure you're adding and adapting the test cases. Both for unit tests that are run and for the artifacts across the entire compose. This is work. Now, it's work that pays off in the long run, but it's work up front that we really need people to buy into, otherwise having gating on CI and not keeping the tests up to date and not adding more tests over time, like that doesn't, it doesn't pay off. Peter. The problem was, when it first came along, I looked at it and the UX and the tools that I needed to know was so goddamn broken that it didn't work. So I tried to enable it and I tried to do the test and basically threw my hands in the air and gave up because documentation was poor, the way it was enabling it was poor and I wasted a whole bunch of time and now it's due to be enabled again sometime in the future, but it's going to be once within the last shot. Okay, so to summarize the soliloquy from the Australian man. The original implementation was broken. We know this, right? It was so poor that people are probably gonna be shy about enabling it in the future. I'm asking you to give it a second chance at the best, right? It's not enabled again. I know it's not, but it's going to be. Let's be optimistic. Yeah, I mean, what I find for a number of times is whether you're talking in time faster, but all we do when we try to do that is we try to jam things in a particular place. It's broken and we trip over our shoelaces and land smack down and basically graze out of it. And so the teams that are pushing these functionalities maybe need to slow down just a little bit so that they actually fucking work before it lands down these rocks in the ocean. And so if they wait just a little bit longer and had some documentation and had some tools that actually work, people may have actually then spent time and you may have actually got a hand for that. So, okay, I'm definitely not repeating everything you said. I'll summarize that. The summary was when we have these systems, we need to make sure that they are well documented and people know how to use them and that they work at least to an extent that they're effective at doing what they claim to do. And while respecting the fact that in open source we do try to iterate, right? So perfect is not an option, but they have to be good enough and they have to be documented so people can use them. Yeah, I guess the only response I would have is that you're not necessarily wrong. I actually agree with most of that. The point I would take away from that is a lot of times people don't pay attention to something until it smacks them in the face, right? Like they literally, unless they have to do something or they somehow hear about it and are interested, they ignore it. And so it's very hard to iterate on a UX and provide the things that people are expecting when nobody's giving feedback at all. So I'm not using that as a defense for the rollout. I'm not even necessarily saying that it's the maintainer's fault because it's not. Like I think there's a middle ground between having something that works and being able to iterate like Paul said. No, I completely agree. And you know, you're using core OS as an example. And the main IoT is another example. Like I have a completely separate release engineering process where I can spin whatever I want. And I mean, I have the knowledge behind do that and I've done it in that way so I can be more independent. So that the IoT working or it can run as fast as we want to, it will need to. But when I look and I want to see everything in IoT because basically I'm lazy and I don't scale that well. And so don't get me wrong. Like I'm quite happy to be the sort of person or the group or one of the groups that sort of trials this stuff. But when I try to sit down and do them, like I'm fairly confated with most of the way the Fedora infrastructure and the Fedora release engineering process and various other bits and pieces happen. And if I can't work it out, everyone else is gonna, you know, be. And so if it's bad enough that I can't work it out I think I heard him volunteering. Yeah, I was just gonna say, like it sounds like you have a solution. Maybe we should have you talk to the people who are trying to implement a solution. Yeah. Steph. So, you know, have taken what I said powerful, probably take five or six, which is exactly the name of the guy. That is how to pace the Fedora capital forward. Like, they don't necessarily step off. So I mean, so I guess the other solution I can see is I guess more people are gonna involve them in us being able to do these things more quickly, to the quality that you're talking about. So essentially, it's possible. I mean, I want to figure out for people who have worked with Red Hat, even the products, the Red Hat was GA and I went in, but it's also music. Yeah. All right, so things need to improve and it's gonna require effort from all of us in this room to help improve them, right? I think that's my takeaway. Can we come back to your point? Because I think Paul has more slides. I do. No, no, no, I'm gonna take another point. So make sure we don't become like a, just a dialogue between a couple of people. Yeah, no, that's fine. Add a comment, Langdon. So, I mean, I think a project is when we hit release date, we think we're done. When in fact, we need to be like, even formally in the schedule, somehow saying, okay, this is six or seven or eight or whatever people that worked on CI the modularity of the structure for something to be true. We need to actually have a schedule that they're gonna be free for two weeks, three weeks, immediately after launch and dedicated to being there and available for problems that will happen because to, you know, to your point, step or play, you still need to go fast, right? So, maybe there are ways we can mitigate it without slowing it down. All right, so I'm gonna summarize that. Remember, when you guys give answers, I have to repeat everything you say, so that's hard. So, so, so Langdon's point was, it's not enough to be done with a project. You have to be there to help educate, help solve problems that come up when people start trying to use it. I would actually add to that, you know, build it into the schedule piece, Langdon, and say, we need time in our schedule to actually improve our tools and not crush ourselves just trying to get the next release out the door. That's a habitual problem that Fedora just ignores. Right. I know we have. Now it's time to get serious about it because if we don't, we're just gonna keep talking about it and nothing will improve. Jim, Jim, we're gonna take. So, you can be part of the solution, you can be part of the problem. All right, hey guys. All right, guys, we're gonna stop dialoguing here. I'm gonna recognize Jim and then we're gonna move on. Yeah. So, you can probably test in your code, test in your platform until we have this release. Yeah, that's a good point. So, let's summarize that. So, Jim Perrin pointed out, which I think he's absolutely right, CI is an iterative process and having a certain tool chain that's broken does not keep us from using another tool chain. It also doesn't keep us from writing tests or coming up with a framework for our testing that we can agree on before we actually implement it. Any of those things we can spend some time on as we go. Okay, so I'm gonna go ahead and move on. So, I don't know if my train of thought is probably broken here, I guess, since... Sorry. But no, no, no, it's fine, it's fine. Comments, questions are always good. So, I think that the key here is that people want applications, right? They want containers, they may want flat packs, et cetera, and those are based on packages. So, what I'm not saying is we're not gonna throw away the baby with the bathwater, we're not gonna do away with the idea of RPMs as something that's important, something where quality really comes through from the community. There's auditable source, et cetera, et cetera. All these ways that RPM packages can allow us to produce good quality outputs for people. But I am arguing that by and large, the rest of the world doesn't tend to be interested in those. There was a time where, and let me back up, because I don't wanna say they're not interested in RPMs. What I wanna say is they are not interested by and large in individual Linux packages, and that might mean RPMs, it might mean Debs, whatever. By and large, the rest of the world has moved on. We have not. That doesn't mean that we should give up RPMs, but it does mean that we need to stop thinking of them as the be all end all of how we build things and what we offer. So, I really, hopefully this is a way for us to kind of take the discussion, I guess maybe away from looking at the RPM as the single artifact that we care about. So, what about applications then? Well, how would they work in this idea? What I've talked about so far is really more about the operating system and kind of reducing that platform down to a smaller level. Well, in this kind of system, our larger important stacks might be able to release on their own timeline. They might do that as modules, as flap hacks, as containers, and all of these are gonna get some airtime here at Flock. So, if you have a chance, I encourage you to go see the talks that are about modularity, that are about flap hacks, that are about container technology. So, some examples, desktop environments, integrated suites or tools, our language support, right? All might be eligible for that space. What I think this buys us is more independent community work around the releases. Well, first, obviously there's the, hopefully the self-explanatory byproduct that if those are able to release on their own timeline, we can actually get them out on their timeline as opposed to on the timeline of Fedora, which is not always a good match. Sometimes it is. I think there are sometimes where it is and isn't at the same time. And maybe a good example of that might be something like GNOME. We tend to not be able to release GNOME directly on time with its releases because it's a very large stack and there's some time that goes by and even though we are on roughly the same kind of cadence, we're on a delay. So on the one hand, it doesn't allow us to release it on time. On the other hand, it has actually bought us something good, which is a lot of times, we inherit the .one bug fix release after the release. And that is good because it means our implementation looks really good when it comes out the gate. On the other hand, we lose the partnership that we might be able to have by releasing on time. If we were able to do both, I think that would be wonderful. So there are opportunities around that. There are also opportunities for contribution around the work of this marketing. Who are the people who are gonna reach out and talk to these different communities and get engaged and help bring the package maintainers in Fedora together with the upstream where needed? If those people are already there, if they're already working closely with the upstream, which often they are, how can they reach out then to people in our Fedora Mindshare community and engage them so that we can have, build up more awareness around the good stuff that we're able to ship on top of a well-integrated platform? So those are just some of the things that we could improve. So what I guess the point that I wanna get at is that there's not really a one size fits all life cycle here, right? GNOME may be an example where we do have a good cadence match, but GNOME is definitely not the be all end all of all open source out there. So there are different life cycles that we could embrace, one being based on upstream cadence. And again, these are alternatives. So these are not to all be done at once. These are going to have different weights, depending on the nature of the upstream and depending on how it fits in with Fedora. So one way to release might be along with the upstream cadence, let that dictate how the release for that stack goes down. Another basis might be releasing on a quality basis, right? Our operating system platform might be managed that way, or maybe not. Maybe there's an application platform that we wanna manage that way based on its integration with Fedora. Initiative planning might involve a stack of software that we need to push out in association with that initiative. So we can have that fit into an initiative planning without regard for whether it's gonna go out on is it going to make Fedora 28? Is it going to make Fedora 29? Rather, we produce that stack and we can use it on top of the platform that makes the most sense. So again, I think part of the reason that Fedora ought to look at any initiative like this is encouraging contribution, right? If any of you saw Matthew's presentation earlier, I know that we have a really good base, we have a really good base of experienced people involved in Fedora. The thing that I worry about and I think that I wanna maybe highlight is the fact that the other bands of new people have not been growing in some time and that to me is a worry. I think that ways that we can encourage contribution and have that contribution come in in a methodology that people are used to using in the open source world is a good thing. So having more automation of integration testing is helpful than anyone can help by contributing tests, right? We have a way to do this, we have a mechanism for this using figure, using the tests repo. So this is a way that anybody can write a test, send a pull request, have it considered and even have that test tested, right? Increasing our linkage with upstream efforts and cross projects sharing. So again, these are ways that our contributors can get more involved with a release without having to be tied in necessarily with to the same deadlines as hundreds of other Fedora contributors all at once basically sucking all the wind out of our forward motion. So working with upstream to boost our ability to get new things out while they are new. Also I wanna note, I feel like modularity deserves to be called out here. I think people don't focus on it largely because we're fitting into a single cycle platform right now, but the problems that modularity solves are important to developers and to system owners. If you're still not up on modularity, you haven't really bought into it, you're not really sure what it means. There are gonna be talks here on modularity. I think Langdon has a talk on modularity happening. When is it? 10.30 tomorrow? And is there anybody else? Stephen, you're given one on modularity as well. Three more talks. So there's enough modularity for everybody. So look up their talks and definitely drop by. To be more useful to consumers, right, those people who are those developers and system owners, we need to pay attention to life cycle issues because they're by and large not interested in a platform that's really only kind of leapfrogging every six months. They want what they want when they want it. And largely they want it to run on a platform that always works. So if we are not paying attention to these life cycle issues, we're constricting Fedora's user base and the outcome from that is that we're also restricting our contributor pipeline because the reason people get involved in Fedora is usually not disconnected from their own needs. It's because they find Fedora works well for them or because they find it fascinating to use and they find that the community around it is a compelling way for them to give back something of what they've gotten from the gift culture that Fedora represents. So again, by constricting the user base, we constrict the contributor pipeline, by consequently by widening it, we potentially widen our contributor pipeline which I think is an important outcome. So in short, I guess what I'm proposing is that we can increase focus on a CoreOS based deliverable as a possible avenue forward. On an agreed upon cycle, it's not my intention to propose a cycle here. I think this is something that the community needs to talk about and figure out what's gonna work best. It may be that that cycle is what we have now. It may be that that cycle is twice as long or half as long, but it needs to be something that will support the purposes that we have in mind. Increasing, by we I mean at the community at large. So increasing automation I think is gonna be required no matter what and so that really directly goes towards efforts like CI. That will help us keep quality high while reducing the manual effort and the heroics that we have to build around each release currently. We should establish some key stacks, perhaps to modularize that are on different cycles from the base platform even using these as straw men to start with. And the implication here, I guess, is one possibility here is moving, there are a couple possibilities. One of them is moving towards a release whenever we want model. I mean imagine a future in which we could cut a Fedora release at any time that we want to within reason and say, you know what, next month we're gonna make this the release. Or next week, who knows. Or last weeks, last week's Fedora was great. It might depend on what those measures are. It may depend on what level of automation we have to give us confidence. It may depend on what level of effort is required around that release kind of like the meta release types of things. But being able to decide that on a floating basis might be helpful. Another thing that Stephen and I were talking about before the break, which I also wanted to point out here, another possibility is having raw hide, either raw hide being the thing that most people are able to run continuously as opposed to just a few hundred people having 80 or 90% of the Fedora user base able to use it would be great. Or perhaps there is no raw hide because something else has taken its place, some stream that we can now use as a target. So in whatever world this is, basically having people be able to live on the edge without it being a bleeding edge, which I think we always want to avoid. So this is directly in line I think with the messaging that Matthew talked about earlier. What we do not want is to turn everyone into a bleeding edge consumer, but being a leading edge consumer is definitely helpful. All right. And so that leads us some time for Q and A in discussion. So again, I know this is a kind of a high level talk. A lot of the mechanics around this, I think are contained in talks that are going to happen around here in flock. Some of you guys are giving them. So as you're thinking about it, you can sort of keep part of this in mind maybe. Actually, Peter, you've had your share of comments. I'm going to go to Laura. We'll come back. I promise. We'll come back to you. We'll come back. So, okay, so the question to boil down is, this talk doesn't seem to propose like radically altering what the Fedora deliverable looks like right now, but could it look different down the line? I think it could. I would actually say it should. And I would say it should maybe sooner rather than later because I feel like the rest of the world's model has kind of gone on without us. And by not focusing on that model, we're kind of losing out on some of the benefits and we're losing out on some of the audience maybe without, and we're not really getting anything in return except a lot of work. I think I agree with you with a twist in that the question was posed as either or, right? There's no reason why you can't continue to produce a Fedora that looks like a Fedora today for a desktop user or a server user or whatever the case may be with variable life cycles and also have something cool and different. I won't even say it's cool. Maybe some people think it's stupid, but fundamental different, right? Like a CoreOS or a Silverblue that moves at a different pace. If you guys remember back when we introduced additions, like part of that reason was maybe these additions have different focal points and they need different life cycles. And because of the way Fedora is built, we literally could not do it. So we're talking about opening up possibilities to do things. Okay, hang on. So there's a few questions. I'm gonna take this woman in about five rows back. All right, I'm gonna have to summarize. That was a really long comment. I think the point was though, not to assume that the base OS is simply one side or one set of packages and one deliverable only versus the applications and that we might have an opportunity to have several different kinds of sets there. Now they might share some sort of common core, but there may be different sets intended for different purposes. I don't think anything here precludes that. And so I think that's certainly something we should keep in mind. I think we should keep it in mind. I also think, I think we should allow for the possibility but I think we shouldn't be afraid to be opinionated either, right? Like people come to a Linux distribution not because they package all the things but because they do it in a way that they curate the content. And so if you wanna produce multiple bases with different variables, that's fine. But each one of those should have an opinion, right? It shouldn't just be some random collection of things that support this one application. Like you should. We already kind of do this in the way Fedora does it but our build system or infrastructure isn't set up to allow what you're suggesting. So I think there's, I think unpacking that there are probably a lot of concerns that would have to be resolved. I think that's gonna be the, that's gonna take the form of probably hundreds or thousands of email messages following this conference. So I don't think we're gonna untangle it all here. I wanna get one more question. Owen and we're gonna be out of time, I think after that because we have one more minute. Is there a place where I see a form, right form discussing all the rules around application? Okay, so the question was, is there a right form for talking about lifecycle? I mean, I hesitate to say but Devel, I mean, that's the one place that we have for these things right now. Is it? Okay, so yes, Cefesco is the other suggestion. Yeah, that's just starting up and I think we can take advantage of some enthusiasm there maybe and not necessarily co-opt it with a lifecycle discussion. But the point is like, sorry. Oh, sorry, Dusty suggested the Container SIG as well as a possibility to discuss that. So it sounds like we don't have one singular answer yet but we should try and come up with that maybe by the end of the week. No, and I think, first of all, that was a very well thought out and posed question that nobody's really addressed ever so I'm glad that you asked that. We did summarize it, right? I think we did summarize the summary. The summary was where is the best place for us to have the discussion about this kind of split and how we enable the sort of different lifecycle in our policy and infrastructure? I think if we wait for one person to decide where we're gonna have the discussion, we're never gonna have that discussion. So let's start it in multiple places and see what we come up with. It sucks from the people who wanna get concrete answers but sometimes you have to drive the conversation as much as you want. Okay. Langdon's been waiting to say stuff forever. He has, we have a lot of, we're a minute over but go ahead, make it short. I will not actually ask the questions or answer the other questions that I wanna answer but I did wanna clarify that you said that some of the world is leaving us behind. That it's not just us. It's all the districts, it's operating systems, it's everybody because they are 100% launching into scenarios where they can do kind of self-perfect solutions to the problem that they have and none of the operating systems are distro so it's making that particular difference easy. Okay. So that goes back to your point as well. Let me summarize for Langdon and then we're gonna be done. So what Langdon said was a really good point. Now I tried to make this more agnostic when I talked about Linux packaging and I did not make it abundantly clear when I said we are not keeping up that the we does not mean Fedora. The we means sort of operating systems the whole Langdon pointed out. I probably would have even just kept it to Linux OSes but I think Langdon correctly pointed out that operating systems as a whole are not keeping up with that space and that's a really good point. So we have an opportunity here along with the problem comes an opportunity. So it's a big problem to solve but if we do it well, it could actually put us at the forefront as opposed to following. Justin, do you have a quick one? So here's the deal. I'm here all week. I have no more sessions. Paul's also here. Hit us up in the hallway. We want to get the feedback. We want to get the questions. We want to have the discussions. Thank you guys.