 The monthly meeting of the Fedora Council, usually we try to handle our business asynchronously through tickets and discussion posts. We do have regular business meetings where we conduct business, but every once in a while we want to take some time and have a higher bandwidth discussion with other parts of the project and really give people a chance to tell us what they're working on, show off a little bit and see how the Council and the rest of the community can help. So this month, February of 2022, we're talking about the EPL project with Troy Dawson and Carl George. They have some prepared commentary here to start and we'll jump into some Q&A, so I'll turn the floor over to them. Okay, here's my screen here, let me know if that's coming through. Looks good to me. Okay, go for it. Okay, as you said, I'm Troy Dawson, Carl George, we're both on the EPL Steering Committee. We usually like to start these presentations with some metrics. We'll keep this short because we only have a few minutes of time. As far as users go, using the UNICIP address counting, we're up above 5 million users. Now that's including EPL 6, 7, and 8, well, and 9. If you do a quick, yes? I hate to interrupt you, you just got started, but for people who might not be familiar with EPL, can you quickly explain what that is? Okay. Sorry, I misunderstood my audience. Let me go back to screen then so that we can see it. EPL stands for, oh my goodness. Extra packages for Enterprise Linux. Thank you, I have those backwards, the two E's. It's packages that are not in RHEL, Red Hat Enterprise Linux, that are compiled for them. Usually, 99.9% of the packages are Fedora packages that are compiled on Red Hat Enterprise Linux so that they will run on Red Hat Enterprise Linux. The EPL SIG is basically the group of people helping do that. We have a steering committee of about 8 to 10 people. I'm the committee chair. Carl George is also on that committee. We'll also talk a little bit later about some of the other things Carl is relating to EPL. What do we want to tell that now, Carl? It's fine, we can do it when the slide comes up. Okay. Thank you for letting us be here on the Council meeting. Is that, I hope that lets you know who we are. We've been around, this is a fairly old SIG, 15 years. It's been a long time, at least 15 years. We'll say that. I wasn't prepared to say how old we were. Okay, I'm going to do some metrics. As you can see we've been around since EPL 5, which would be RHEL 5. I think we might even have some RHEL 4. Yeah, there's an EPL 4 GPG key, so I think we've been around since then. Yeah, so it's been pretty early. It wouldn't even surprise me if there was at least discussions with RHEL 3. But I think it formerly went with RHEL 4, starting with EPL 4. As you can see from the graph, we started off slow and nowadays we're up to over 5 million users doing all of our releases. A little bit of a breakout for that. Right now our most popular release is EPL 7. It's got the most packages, it's got the most users. And right now we have EPL 9, but it's so small. We're up to 2,000 users, which is actually pretty good considering RHEL 9 isn't released. So EPL 9 is our latest one. I can comment too much more about this at the moment. Maybe if people want to ask questions they can later on. So if we do the other graphs for unique IP addresses, there's the new count me system. But this only has EPL 8 and EPL 9, but EPL 9 again doesn't show up on here more than a blip. So EPL 8, we actually are up to a million and a half, or we're up to a million and a half. As you see on the other page, we weren't even on a million on unique IP addresses, but with the new count me system, we got up to a million and a half. And then there's a little blip. Also worth noting that this chart's used in the count me system which is only available for EPL 8 and EPL 9. The mere stuff has 7, 8, 9 and also the historical ones you saw on that chart. That's correct. Thank you. Thank you, Carl. I'm going to let you talk on these. Sure. So these are some additional charts. I'm fudging these together. I'm not a data scientist, but I'm tinkering with Matplotlib and making these. I owe Matthew some work integrating these with his other tools so that way we can just generate these at the same time. But we recently launched EPL 9 and it's, as you can see, it just starts there in December. And it's already climbing pretty quickly. The rail systems you see in that chart, I imagine most of those are rail 9 beta systems. But there may also be some internal deployments of rail that are already consuming EPL. And then we can see that the Centoestream 9 systems are already up over a thousand and still growing. And mind you, these are just systems that have EPL 9 enabled. There are probably plenty more. I think in another comparison that Smooch has been working on, I think you're seeing like one out of every five systems as a ratio for systems that have EPL enabled. I'm interested to see, this is the first time, 9 is the first time we've been able to get that kind of ratio because it's the first time that we have both EPL and the base Centoest distribution in Mirror Manager reporting those count me statistics. For Centoest 8 and Centoestream 8, those were on the older Centoest mirror infrastructure. So we don't have that metric to compare. I'm interested to see if that stays the same over time. I think it will grow. I think most systems end up having EPL enabled just because of the small focus set of packages that are in the base distribution. We can move on to the next lecture. But here is EPL 8 systems as opposed to the EPL 9 ones. As you can see, these are obviously on a much higher scale. The Centoest Linux 8 systems, we're reaching up over 500,000 there. They've dropped off considerably. What we think is happening there is that we don't think those systems went away, but with the Centoest Linux 8 early end of life, DNF is checking the repositories alphabetically. It hits the AppStream repository first, which is part of the operating system. It's getting 404s from the old legacy mirror system, and DNF gives up and stops checking the other repositories. So it stops hitting EPL. We think that's our theory about why it's dropping off so quickly there. I'm not going to kid ourselves and think that people are migrating off of it that quickly. A lot of people are still finding out about that news and migrating slowly. It'll take some time, but I think that's going to actually spike back up for 8, as people find out their repos aren't working and switch over to the Centoest vault temporarily until they migrate to something else. But that'll be interesting to keep watching. All the other lines below here are much smaller, but you can see rail, Centoestream, and a lot of the other rail clones that are coming up. All of them are growing quickly. I expect them all to keep growing as more and more people find out about the Centoest Linux 8 news. Go to the next slide, Troy. Okay, so we, I'm sorry. Over the past year, that's what sort of what we're going over on the rest of these slides is what has changed over the past year. One of the things that you might have noticed in these slides is we have a new logo on the left is our old logo. And that, that worked for the time, but it doesn't scale various things. People didn't even know it was there. I'm the right in very many places at all. Nope. I had to search to find it. Well, it was all on one wiki page, one wiki page. The new on the right is our new one. We had, thank you to the Fedora graphics community helping us work through that. I think it looks pretty good. Oh, also in the last year. Red hats used towards Apple has changed. Carl, do you want to go over that or do you want me to. Sure. So the historical context there is that rail customers have regularly told red hat that they don't migrate to a new major version of rail until all the packages from third party repositories, especially Apple are available. They understand that everything third party doesn't get support from red hat. But for a lot of the software they use, they don't actually need support for it. They have a base operating system and then they understand that, you know, one or two critical tools that they use, they get from a third party, and it's community supported at best. But that doesn't change the fact that the availability of that software for each major version affects their plans about when they adopt that major version of rail. So red hat started taking an interest in that enough enough customers gave that feedback that we started, you know, we as in red hat started paying attention to that. For a long time, there is push for the community platform engineering team, the team that me and Troy work on to take on that work just outright. Correctly, our managers push back that we'd love to do that. Give us headcount. We're not just taking it on additionally. And in September, we announced that that actually happened. We got more headcount approved so that CPE could take on Apple work officially. That doesn't mean that Apple packages are supported in any way. It's just that red hat is officially staffing the resources for Apple. Kind of in line with how they staff everything, everything that red hat provides for fedora itself. We're just kind of increasing the focus and attention that Apple's going to get directly. That is a sub team within CPE. I was the first member of that. We've since added another CPE member Diego Herrera. I'm hoping in the future we can add more team members. And even if the team stays small at two, just being part of officially CPE responsibilities makes it a lot easier for everyone in CPE to spend their work time on it, ad hoc as needed rather than on their free time, which is historically how Apple always happened. It was always just a labor of love, a side project that would happen, you know, weekends and after hours. And that's how it would usually get the work would usually get done. That is paid off. I'll talk about how that's paid off when we get to the Apple nine slide, but it is already paying dividends. Yep. I do want to clarify, although I do work for red hat and although red hat is sponsoring some things like Carl. Even though I'm the committee chair, I'm not a committee chair as part of red hat. What am I trying to say Carl? I'm not paid to be the committee chair. You're an example of what I was talking about. Yeah, you're not your official responsibilities aren't Apple, but because CPE now officially takes care of Apple and staff's Apple. You don't mind at all putting down that you worked on something Apple as part of your, you know, routine work, rather than doing it on your free time. Yep. Yeah, they basically what you're trying to say. That's what I'm trying to say is I work for red hat. I work on Apple. I do work on Apple during my read through my work hours and off my work hours, but I am not paid specifically to work on Apple. Now, Carl, you're you are paid to work on Apple, but you're not paid to work on Apple packages. Is that correct? Basically, although you can work on them on your spirit. Any of the Apple packaging work that I'm doing that is one thing we wanted to be clear with the community and with other red hatters and customers is that CPE is not turning into a package delivery service to fulfill wish list items for Apple. It is still a community repository. The work is primarily done by community members. And if somebody asks red hat to get a package into Apple, their response is, here's how you can do it yourself. That said, with dependencies and interrelated things, there are plenty of things, plenty of packages that I do work on an Apple to help enable other packages in Apple. I don't want to be a blocker for anything in that. I'd consider that part of the responsibilities, but it's a little bit fuzzy because, like I said, we're not directly just doing a wish list of, hey, what packages do you want? We'll throw them in there. It's more about enabling community members to add the packages they need and unblocking them when necessary. Some of that also involves adding tools that red hatters and CPE needs in Apple. For example, I just wrapped up yesterday, Troy gave me a hand with some of it, getting the sent package tool, which rail developers need for building CentOS Stream 9 and doing their daily work there into Apple 9. So that'll let them start dogfooding, running Stream 9 to build Stream 9, hopefully. So that's the main thing is that it's not a package delivery service, but we do do a good bit of packaging just as a matter of supporting it in general. Yep. All right, let's move on. Fedora docs. Apple's had documentation from the very beginning. And it's always been on Fedora Wiki. Wikis are good to a degree but at some point, they're not. To the official Fedora docs that happened this past year. That is made things a lot easier. First, there's no random wiki pages that people pull up that I've never seen before. And when people do want to have like a change in policy or even just fixing a few words here and there, they can do a pull request. And it's made it much easier. One of the other things Carl's also brought it up is we've written a nice page that tells people how to get packages into Apple. And it looks so much better in docs. It's easier to give them a nice short URL rather than explaining it over time. Now we give them a URL that is, I describe it as kind of a choose your own adventure guide. Troy, he's not taken enough credit. He wrote most of it. We've done a few improvements here and there, but it is fantastic. You start at that and you can go through. I am just a user and here's how I file the bugzilla or I'm a package. Here's how I file a bugzilla and offer up to be a co-maintainer if the maintainer isn't interested in putting it in Apple and several other scenarios like that. It's really useful. And that's, I think that's helped get more packages in because before with the wiki, it was fairly vague and we got asked that all the time. Anything else on docs, Carl? No, you mentioned that the biggest thing is that now we have the pull request model for improving those, which is huge. And it aligns us with, you know, the rest of Fedora docs, which is always a good thing. Apple is part of Fedora. So doing, doing our documentation just in the wiki doesn't really fit with what the rest of the project's doing. Okay. Apple, I'm going to call this Apple next. Carl, since you were the co-create co-create, you, you were the driving force behind this. I'm going to let you take this one. Sure. So Apple next is something we started doing this past year. I think we start launched it in July. And to understand what that is, you kind of have to understand the relationship between CentOS stream and rel and how that changed. Historically, CentOS was a rebuild of rel, a clone. And the goal was, it was never identical, but the goal was to be as close to rel as possible. So it would, it would follow kind of downstream of rel and try and keep all the same library versions and everything identical. That made Apple work, you know, it would be very rare for a package to install on rel and not on Apple. It would happen occasionally in a short window after a rel minor release if a library got changed. But then all that would have to happen is the Apple Packager would rebuild their package, make it compatible with rel again. And then there'd just be kind of this weird window, usually about a month where the package may stay broken in Apple. So that way it kept working on CentOS, which we know has more deployments than rel. And then once CentOS caught up with rel, they would do the rebuild in Apple and it would work everywhere. So it would kind of stay broken on rel for about a month. Which wasn't great. Hopefully some of the new rebuilds, they're getting, they're putting more resources into their rebuild work. So that, and they're turning around much faster than CentOS had historically. So hopefully that window is shorter for them. But Apple Next is helping with where CentOS moved. CentOS is now just upstream of rel. It kind of leads rel by a minor release. So right now CentOS Stream 8 has rel 8.6 content and even though rel 8 is still on 8.5. There's not any examples where it's necessary right now. But going back a release when rel was on 8.4 and stream had 8.5 content, there was a rebase of the QT5 libraries from 512 to 515. That happened, like I said, that was an 8.5 change. It happened in stream 8 like four or five months before it got released in rel. And that meant that everything that linked against QT and Apple would no longer install on stream 8. That was not a good thing. We were telling people that, you know, CentOS Stream is still a good operating system. You can still use it. It's not just a development platform. And for most people that's true and it works great. But then small edge cases like this where an Apple package won't install or any third party package won't install. It can make things painful whenever rel is evolving. So in order to deal with that disparity where CentOS was leading rel by about six months. We came up with this idea for Apple Next. Apple itself builds against rel. But in order to make compatible packages for these type of changes. We needed a separate build route and separate repository for packages to target that built against CentOS stream instead. So now if you do a regular Apple 8 build against builds against the current rel 8 content. And the vast majority of the time 99.99% of the time that works on both rel 8 clones and CentOS stream 8. But when you hit one of those edge cases like the QT thing. You need to target a different build route Apple 8 Next. That lets you build stream compatible packages, publish them in a separate repository. And then users can consume those to get a higher version that works on their on their stream 8 systems. It also works well for the rel 8 betas. Whenever those come out before a minor release, they can users can use Apple Next in order to get compatible packages in the same way. That's kind of where the name comes from next. It's for the next minor release. I want to bring up one thing. They don't have to recompile the entire Apple release. It's just those packages that are different. The Apple Next thing layers on top of the Apple. So Apple in order to have Apple Next, you need Apple 8 and then you layered on top the Apple Next repository. So it's a separate build route, but it's not a completely independent repository. I was working my way towards there eventually. Oh, sorry. That's great. Keep me on track. We need to hurry. Yes, for it's a separate build target, but in use. Apple 8, Apple requires Apple Next. So you use them together. And most of the time you won't be using anything from Apple Next because everything in Apple is compatible. But if there's something in Apple that's incompatible, Apple Next allows you to get your compatible package if you're on stream, but not if you're not affect the rail users that are using just Apple by itself. So this was the solution we came up with. It's not perfect. There's a few little kinks with overrides and things like that. For the most part, it's been really useful. It helped a lot with rail 8.5 readiness, that QT thing and a couple of other changes. And right now I'm not aware of any big changes between 85 and 86 where it's even necessary, which just shows the point that it is a useful thing when you need it and you shouldn't need it very often. We've also launched Apple 9 Next in conjunction with Apple 9, but it is also not currently needed for anything, but it'll be there ready once stream 9 has content that is not in rail yet, which will happen probably over the next year or two for sure. Let me transition to the next one because I think that seems like an Apple 9. How can we have Apple 9 yet if rail 9 isn't released yet? Do you want me to answer that or do you want to answer that? Either way, I can go. So, yeah, like you said, for the first time ever, we've launched Apple 9 before the corresponding rail version. That was only possible because of CentOS Stream 9. At this current, we mentioned on the last slide how Apple Next builds against stream at this moment in time, Apple 9 and Apple 9 Next build against CentOS Stream 9. And that is only because rail 9 hasn't launched yet. Our intention is what we plan on doing is freezing the infrastructure mirror of CentOS Stream 9 prior to any 9.1 content showing up. We don't really talk about it exactly publicly, but we are aware of the internal schedules for that and know when we need to do it. The idea is that maintainers don't have to think about it at all. They just target Apple 9 as the general rule. And then some point later on down the road, rail 9.1, 9.2, if they notice something in stream, one of their Apple 9 packages doesn't install on stream 9, they can, at that point, Apple 9 will be building against rail 9. They can do an Apple 9 Next build and get a compatible build the same way they do with 8 now. But at this current moment in time, it's not necessary. So in summary, right now build on Apple 9 like you're building on rail, because what it is is pretty close to rail GA. Stream 9 right now reflects 9.0 content. Yep. So that's going to help us get a lot of, this is a big pressure we had internally. Originally the plan was to launch Apple 9 Next standalone and leave that for approximately six months and then launch Apple 9 after the rail 9 launch. But explaining to maintainers that you target Apple 9 Next for six months and then you target Apple 9 unless one of these other scenarios then you target Apple 9 Next again. It was just getting way too complicated to explain. So we kind of revamped our plans and just went ahead and launched Apple 9 outright to keep things simple for maintainers. That has been a big success. We're growing, Apple 9 is growing really rapidly. As of this morning, it's up over 3,600 RPMs, almost 1,800 source from 1,800 source packages. Over 1,400 updates have gone through Bodie for Apple 9. And it only launched, I believe it was first week of December, if I remember right. So it is just growing faster than we've ever seen before for an Apple release. And for the first time ever it launched before the corresponding rail version. Typically Apple would take three to six months to come along after rail launch. So this is going to help with that third party ecosystem of packages having those ready to go day one of rail 9 launch, which was a big business focus that we were getting input, getting the feedback for. Yep, I'm going to move us along Carl because we're a little short. Apple 8. Over the past year. Apple 8 we've already talked about Apple 8 next I'm not going to rehash that. One of the other big things is we recently retired Apple 8 playground. To be honest, I'm not even go over that we playground was a nice attempt, but in the end, nobody was using it and it was becoming more of a burden. But that has been decommissioned. In favor of copper, I would say most people use that same spirit of things. Yep, I think, and I think that it already happened as people just started using copper. I can't see my notes. Carl, do we have any other Apple 8. One of the problems we had with Apple 8 and getting content added was that started in a real late row was a lot more intentional about what packages were shipped. That's the kind kind way of phrasing it, you know, a focus on what they want what red hat wants to support. The unkind way to look at that from the community's perspective is red hat held back a whole lot of devil and other packages like that, which prevented packages from being added to Apple. It's been a painful experience, but it's getting a lot better. We've got a process ironed out now where not you don't even have to be a customer. You can file a bugzilla anyone can especially Apple Packagers can file bugzillas to rail to request devil packages be included in the CRB repository. That allows that allows Apple packages to build against them rather than just having them in the build route for rail packages only. Other packages have been added because of that. Not all of them. Sometimes the rail maintainers say no. There's a lot of specific nuance detail about why they get added or why they why they say yes or no. But on the whole it's been a positive improvement, but it started in kind of a bad state, but it's getting a lot better. I think that changed about the same time that red hats attitude towards Apple changed. Yeah, I think that all played into the same thing because with with the lack of packages in Apple eight that kind of brought the focus to customers not wanting to migrate to from real seven to real eight. And the answer was the package I need isn't an apple eight and then drilling into why that's the case. Well, Apple's not staffed and also there's these missing development packages. So it all it all kind of factored into the site to where we're at now. Yep. Swinging back to documentation that page is getting worked on. We at least have a working draft to make it easier for people to, to request those and to fix, fix the problem. Yeah, I think right now it's just an FAQ item and it probably didn't merits its whole entire page. The only other thing was the mock config changes but I think we can skip those. Yeah, I don't know real quick. I think that's going to, we're getting a little short on time I'm going to mock config changes look it up. How's that Apple seven, we still have Apple seven. It's still being it's still to be honest it's actually still healthy. People are staying on seven for a long time and adding packages updating packages. It's still healthy. It's old, but it's healthy. Maintainers. So this is one of the things that we think will help Apple long term is getting more and more maintainers. A lot of the maintainers. If you're a fedora maintainer it's very easy to become an Apple package maintainer, but not all fedora maintainers want to have that long term commitment. We did notice. So we got some nice numbers here. Sorry about that. Apple seven like I said it's a nice healthy community, a set of packages being maintained. We've noticed over the years that there's sort of a 10, 10 packages per maintainer ratio that does not mean that every package has 10, some have hundreds, and some have one. But we're trying to get that the number of maintainers for each distribution up is more maintainers means more packages usually means a better environment. Even just today when I was updating for Apple nine, I saw that we had, I think, seven more maintainers than when I updated this just two weeks ago. So we are growing on maintainers. It's actually been three months since Apple nine was released should have changed that. But as Carl pointed out earlier when we he's talking about Apple nine. These other ones Apple seven has been around for eight years Apple eight's been around for three years and Apple nine has been around for three months. And it's already almost got half the packages of Apple eight. Apple nine is people are really enjoying it. Oh, thank you. I, that's one of the great thing about having docs online. So, anyway, if you want to be a maintainer, whether you're a fedora maintainer or you just somebody in the community saying hey I'd like to. We're trying to reach out as much as possible we're trying to make our documentation better. And come, come see if you got that package you really wanted in on your rail system sent those Alma Rocky. Can bring it into Apple. You don't need to hide it over on your on your web page or on your separate thing. As long as it has the right license. Let me clarify that and doesn't override anything in real and doesn't override anything real. We do have some rules about being extra packages. Yep. Yeah, maybe I need to clear clean up my recruitment statement. Anything else. I think that's good. I'm ready for q amp a. All right, questions and answers. And I'm actually going to close this so we can see people. Anyone have any questions from the audience. Feel free to jump in on video and or voice. Or we can put them in the chat and I can read them out. I don't see anyone reaching for the unmute button so I'll ask a couple that I thought of. Okay. So, you know, you talked about Apple packaging being done by a lot of times of the, you know, for the packages of the package in the fedora or whatever. So what exactly does the Apple SIG do. So there's, there's two. Let me clarify that the SIG. There's actually two six. There's sometimes we call the Apple packaging SIG and that's a little group that we've gotten together of, of doing things but the Apple SIG as a whole. I'll be honest until six months ago I didn't know we were a SIG. Even though I was the committee chairman. The SIG as a whole does, yes, we do packaging and maintainers that last slide. That is the vast majority of the work done is package maintainers putting building packages in things. So, technically, if you are a fedora maintainer and you also maintain something in Apple, we're going to consider you part of our SIG, part of Apple. We don't always call ourselves a SIG. We usually just say Apple, the Apple community. Is it a SIG or a sub project? Yes. Yes. We're, we did have a discussion on whether we were a SIG and we decided let's just leave it that way because everything's in place. Let's just rock the boat on the fedora side. Honestly, the big thing with the SIG is that we, we kind of did, we, we coordinate the, the Fedora release engineering still handles a lot of our infrastructure side things. But there's some overlap in membership between Fedora Relinch and the Apple, Apple SIG and Apple steering committee. I would say the big thing is that the Apple SIG coordinates all the infrastructure and release engineering needed to make Apple happen and have it available for all the packages to get involved and add the packages they want to see. Thank you, Carl. To be honest, that's a question that nobody's asked me, so I've never even thought of it. It would be good to get some guidelines around delineate between what does the Apple, Apple SIG do versus the Apple steering committee versus the Apple, the Apple packaging SIG. We should noodle on that some more. Yep. Right now it's sort of everything. Did you have a second question? Yeah, Marie asks in chat, are there ways we can help support your work on Apple? My first idea would be to suggest a survey if that would be useful. So, there's, there's several ways to help on Apple. One is documentation. That's one of the reasons we put things up in Fedora docs is, is some people could help with that. The other is maintaining packages. So one of the strange things about surveys and stuff and we show how many users we have. And to be honest, that doesn't affect most people. Most people working on Apple are doing that because they personally want to do things like I personally run the KDE desktop. And so I want to make sure it's the best it can be. And that's what I, one of the main things I do, or they do things for their company. And that's the companies paying them to do X, Y and Z. So, so we're not, we've talked about surveys before and we just don't know what to ask people. Unless you think of something that I hadn't, Carl. I would, I would be very interested in a survey. I'm not sure of exact questions and input helping us come up with survey questions would be very actually for the council to get involved with. I think it'd be okay for the survey to be pretty short long surveys get kind of annoying anyways so, you know, two or three questions would be really good. Maybe something I see Vipple in the chat saying he can help with the survey maybe I need to get with him then and brainstorm a few questions we can, we can talk to you about it to Troy and others, but yes, getting more intelligence about what, what Apple maintainers and I should just say Fedora maintainers because part of the things that I would ask, I would target the survey at Fedora maintainers and ask, you know, how many of them participate in Apple. If they don't why not things like that, that would be useful intelligence so that way we can. We can help shape policy and our, our focus in the future to get convert more get more of those for our maintainers involved in Apple as well. So I see another question in the chat and I'd really like to address this one. So can you speak a bit on the expected support lifetime of Apple packages versus for door packages. This is in regards to maintainer support. Well, it's in the policies and a lot of people miss this and maybe we need to bring it up, but an Apple Packager only needs to maintain package as long as they want. A lot of people, and we do stress that, to be honest, we would, we'd like you to stay the whole lifetime of rail, and there is the API support thing. If you change jobs and do things or let's say I switch from KDE to XFCE. Probably not going to happen, but let's say we did that. You, to be honest, this is something I wanted to bring up in the community. We'd like to get something similar to orphan but not an orphan something where you can say, hey, I'm no longer going to maintain this because right now the Apple policy basically says you can drop it. It doesn't happen very often because because they need to maintain the API support, a lot of Apple packages just sit there. A lot of the Apple seven packages have not been rebuilt or done anything for the whole life of the thing. The idea is kind of to maintain Apple packages in a similar fashion to rail itself. Yep. But if you do want security updates only and only update doing avoiding major upgrades version changes if possible. Anyway, the way the policy currently is worded, you can drop something if you want, we suggest you bring it up on the Apple develop and say hey, I want to drop this and anybody take it. Otherwise, I'm going to retire it. But you, but you can. Which is similar to how it works for Fedora hide it's just for Fedora, you're not allowed to buy policy not allowed to retire packages. In the general case from a from a stable release once it makes it in there so retiring a package on Fedora in Fedora means you keep maintaining like right now your f 35 and f 34 packages until they're into life. And then you can retire it on on raw hide. I'm not sure how that works with branched. I imagine at some point that policy takes effect for the branch release as well. But with Apple due to, you know, Fedora releases have a roughly 13 month life cycle. So, 10, you know, saying hey, make sure to maintain you have to keep maintaining it for the remaining 13 months is not a big deal. Saying you have to keep maintaining it for the remaining 10 years of this life cycle is a lot bigger asks so we don't do that. Or don't mandate that per se definitely appreciate it and recommend it. Right. I hope I hope that answered. Was there and then did you have another question. I had another question. Yeah, and this is one I could easily probably search for myself. But does Apple offer flat packs or is it just our PMs. It is just our PMs. We do not. As far as I know, we don't have the infrastructure to do flat packs. Also, I don't think there be any value. I don't think there be any value there either because. Fedora flat packs the Fedora flat pack remote and. What do you call it a flat hub those work on rel as far as I know, and they pull in their necessary runtimes. I think the whole point of Apple is to rebuild Fedora source, or sources for the RPMs. On a compatible release of rail because they don't have like flat to have flat pack runtime libraries. Since flat pack kind of brings its own runtime that's that's just not necessary. Any other questions. Maybe we appreciate the support that Fedora has given us over the years. I'd also like to think the, as far as I know, this is the first time we're in here. I'm the current committee chair, but there's committee chairs and council members before both me and Carl, that I think this past year we're reaping the benefits of past Apple people's works. They've been pushing the rock up a hill for a long time and we just happened to get to the top and we're. We're going with what you do. So those of you are four bears. Thank you. Talking about you smooch if you're watching. Yeah, I do want to name a name, but he's done a lot. There's also been others with him. Kevin, Kevin has been been pushing that rock for a long time too. Yes, shut all credit workers do Kevin and Kevin and smooch are great. Several others. Of course, those are the two most notable as far when we're talking about it in a historical long term pushing that rock up the hill. I think they've probably been doing it the longest, I would say. Yeah, I think so. I think they were part of the original Apple. Group. And I know Kevin was, I think smooches. That kind of fits in with what we were talking about how it kind of historically it's been a kind of a spare time thing for release engineering just to. They're kind of the blocker on getting the infrastructure up so the repo can exist in the bill targets and all that stuff. But that was, you know, that was kind of the end of the involvement, get it up and running and then let the maintainers take over and do what they need to do. So release engineering supported us really well in that way, doing it in their spare time. And now with see with Apple being a staff CPE initiative. Now they can, you know, they can block out their calendar with stuff and say, hey, I'm working on this official CPE initiative today. And that's that's helped a lot. So it's great. Well, we appreciate your time and all of your effort for Carl. Thanks for joining us today. Her next video council or council video meeting will be on March 10. And we'll be keeping on the enterprise Linux theme. We'll have Steven Gallagher and Justin Forbes here to talk about the enterprise Linux next big. So tune in for that live blue jeans or catch us later on YouTube. So with that, thank you again, and we'll see everyone on the internet. Later. Thank you.