 Hello, everyone. I'm Mohan Badu and this is my friend here, Carl. We both work for CP team in Red Hat. So as part of our jobs, we work on a lot of open source projects, which includes Fedora, Apple, and CentOS and CentOS Stream. Today, we are here to discuss about what is Apple Next and how is it related to Apple and what are the future plans for Apple Next and how we are going to create Apple 9 from Apple 9 Next. So with that being said, let's dive in. First, we need to understand what is Apple. I guess there were a couple of talks before, including tries just before hours, explaining what is Apple and usage statistics. As Mathemula mentioned or Troy mentioned, Apple is one of the most downloaded parts of a downloaded project of Fedora. Basically, it stands for Extra Packages for Enterprise Linux. It's the extra set of packages that are not shipped in rel. So people can use these packages in their systems. Currently, the way that we are developing this, Apple is basically we take a rel build route when our rel goes to GA and we keep updating that build route periodically. And people who want to maintain the packages that are not part of rel can request an Apple branch in Fedora Disk Kit and build those packages against the rel build route that we created. So that leaves the question of what is Apple Next and Carl, you want to take that up? Sure. To explain Apple Next, we really need to understand better about what CentOS Stream is. I've talked about this in other talks and you've probably heard about it in the tech news and things like that. CentOS Stream describes what's happening in the CentOS project. The classic CentOS model that was what people used to know, that was where the rel publishes its source code and the CentOS project came along to rebuild that source code into another distribution that was as close to rel as possible. It wasn't identical, it wasn't perfect, but for a lot of people it was functionally the same. That was very useful for a lot of people. It built a good-sized community, but a problem we had there was that it was mostly a community of consumers. There were very few people that contributed back, mainly because it was almost impossible to contribute back. The only way to contribute would be to help other people use it. We had some great volunteers in forums and IRC and things like that, but it was always usage-focused. You couldn't change anything in the distribution. What you got was what you got, just whatever red hat threw over the fence, which is not a way to build a healthy thriving community or ecosystem. We've realized that and what we're trying to do now is move CentOS upstream of rel. Now, some people may be confused by that and think, wait a minute, I thought Fedora was the upstream for rel. It is. Rel has two upstreams now. A simple way to think of it is, an oversimplified way to think of it is that Fedora is the upstream for the next rel major version. CentOS is becoming the upstream for the next rel minor version, because red hat has a policy of pushing changes upstream first. If you want to get something into rel, the answer usually is it should be in Fedora first. Likewise, if you want to get something into Fedora, it should be in an upstream project first. Now, that makes sense and that works, except for once rel branches off from Fedora development, getting a change into Fedora after that point means waiting multiple years before you see it in the next major version of rel. There was no way to contribute into the current version of rel, and that's what we're trying to solve. There's been a lot of talk about compatibility problems or the potential for compatibility problems. And the thing to understand there is that CentOS stream is as compatible with rel as rel is compatible with its own minor versions, say 8.3 to 8.4. That is to say it is very compatible, and occasionally there are things that are incompatible. There's a whole document and process for how rel handles that, the application compatibility guidelines, and every once in a while a package that is on a lower level defining that document might have a version change in the next version of rel, which will be reflected in CentOS stream. Right now the main problem we have with that is QT in rel is at 5.12 and has been rebased to 5.15 in CentOS stream. And that brings up problems with packages, say an Apple that link against QT. Those packages need to be rebuilt in order to be fully compatible with CentOS stream. And that was the problem that set the stage for what we wanted to achieve with Apple Next. We came up with the idea for this, and what we wanted was to be able to enable packages to rebuild these packages when necessary. It operates somewhat like Apple testing does. You're not using Apple testing by itself. It's used in conjunction with Apple itself. The difference here is that there is an additional build targets and branches for Apple Next, because rather than just being short-lived like an update that isn't in the testing repo for two weeks, this may need to live for six months until it's in the next public version of rel so that way it can be rebuilt in Apple proper. So we have additional branches and the Apple branches, the Apple build route builds against rel. The Apple Next build targets will build against CentOS stream. It is a per branch opt-in. So just because you maintain an Apple branch, you don't have to participate in Apple Next. And in fact, the vast majority of packages don't even need it at all. The last time before the QT thing happened, before that rebase came along, gathering statistics on it, of the packages in Apple that installed cleanly on rel 8, over 99% of them installed just fine on CentOS stream with no other changes. But if the package you want to install is one of those less than 1% packages, you don't care how many other packages install fine. The package that you care about right there doesn't work and that's painful. So we wanted to solve that pain point or at the very least give maintainers a way to solve that pain point for their users. So we launched the first version of Apple Next is Apple 8 Next. It corresponds with each Apple branch. We launched that back in May and we've had almost 376 builds so far when we were gathering the statistics for this talk. So it's already getting some uptake. The vast majority of those are thanks to our previous presenter Troy doing getting QT and KDE things prepared and ready for the next major version of rel. The good news is and what that helps everyone with is that he can merge those changes from the Apple 8 Next branches to the Apple 8 branches whenever rel 8.5 launches and have Apple compatible with rel 8.5 much faster than it would have been able to before. In the same way that CentOS stream helps anyone prepare for the next version of rel Apple Next works with that to prepare you to prepare Apple for the next version of rel. So that I mentioned that we just have that for Apple 8 Next right now. Mohan, can you tell us about Apple 9 Next and what we're doing there? Yeah, so Apple 9 Next is basically it's built against CentOS stream 9. So we are currently working on that early this week we were able to mirror the CentOS stream 9 content. So we are planning to set up the Apple 9 Next as soon as possible probably in the coming weeks. And we wanted to use this Apple 9 Next we wanted to leverage Apple 9 Next in building Apple 9. So how it is being done we are going to explain it now. So Apple 9. So previously what happened is whenever rel goes to GA all the Apple maintenance will request the branches for Apple. And then whenever based upon the dependency order and everything they sorted it out and then they will start building some content in Apple 9. It takes months to have something usable. But with Apple 9 Next we can leverage the packages that are already building in Apple 9 Next create Apple 9 branches that already have Apple 9 Next branches. So it's basically you're opting in it's an opt-in for Apple 9 Next but when you opt-in for Apple 9 Next you are automatically getting Apple 9 as well. So whenever rel goes into GA the release engineering side create the Apple 9 branches that has Apple 9 Next branch for the packages and we run a mass build of all these packages against the rel 9 build route. With that approach we are going to have some usable Apple 9 within few days of rel GA which is a huge huge advantage for all these distros including rel and all the rebuild distros because rel by itself has less number of packages and Apple is a huge thing on top of rel and other other ribbons. And with that we will take any questions. I wanted to clarify one thing real quick Mohan we mentioned how when rel 9 goes GA our plan is to take all of those Apple 9 Next branches and create Apple 9 branches do a mass branching and then attempt a mass rebuild. I mentioned before that Apple 8 Next is opt-in you can just do an Apple 8 branch and ignore Apple 8 Next if you want to. The inverse is not necessarily true because the way we're looking at it is if you're requesting an Apple 9 Next branch you're also planning to do the equivalent Apple 9 branch because ideally you will just be able to move your package into Apple 9 and then not ever have to even rebuild in an Apple 9 Next again. If you do it's there for you but then that should still be short-lived up to six months until whatever change that necessitated it is in rel proper and then you can just focus on the Apple 9 branch again. Exactly. There is an API change that is incompatible with the minor version release then they have to rebuild in Apple Next branch but most of the stuff in Apple 9 branch will work on both center stream and rel. I don't see any Q&As yet but Neil says that we should make sure Katie Plasm is the first thing in Apple 9 Next and Troy is going to see that. Yeah. Yeah, just Katie itself will add what maybe 200 or some packages Troy. I just want to oh 400 some packages but the dependence is 500. I just want to mention other thing like the mass build we will be running after the rel 9 goes here we might be running in multiple times just because the way the mass build is done is by alpha numerical order so some of the dependencies might not be caught or not properly built in the right build order so yes Neil it's a dumb mass build yes so we have to run it multiple times to capture all the build dependencies. Make sure to go over to Q&A and submit your questions if you have any questions on the scope of this talk Neil. I know you want Neil I know you want OBS and Fedora but has okay let's see there is a Q&A what's the GA of Apple 9? So no one's going to say for sure when that is because we're going to do it as soon as possible after rel 9 GA no one's going to give you an exact date for that either but we but Red Hat has stated publicly in several places that we're now on a three-year major version cadence so you can look at the release date of rel 8 and say approximately three years from that is when rel 9 GA is going to happen then like Mohan said we're hoping that within a few days of that we can have an initial set of packages in Apple 9 based on the work people have done so far up to that point in Apple 9 next. So there is a question from Neil will it be possible for Apple next branch to be deleted after the content is synced into Apple branches on most either so I don't think we can technically we can. In theory you can retire the branch then if you need it again un-retire it but that seems unnecessary. Yeah that's a thing like for some reason they want to go through adding an extra branch they have to go through with a federal request request branch process if they want they can retire Apple next branch and whenever they feel like they need to build it again in Apple next they can un-retire it. My thought process is that if your package needs a next branch that means some of its dependencies are at a lower ACG level and if that means if they were rebased once they could be rebased again so it doesn't make any sense to retire the next branch during the life cycle of that set of Apple branches. I'm going to do a pseudo Q&A that no one's asked but I'll point out there anyways because I just realized we should have put it in our talk also. Some of you may already be using Apple next if you're using CentOS stream mate and that's because we added a conditional week dependency inside Apple release so that way if you install Apple release on CentOS stream mate it will conditionally pull in CentOS release. So some of you may already have that enabled to not even realize it and the idea is that that will work seamlessly because it doesn't have newer versions of every package in Apple. It is only rebuilds of packages in Apple 8 that need to be rebuilt to be compatible. The idea is that you'll just be able to DNF install the package name you want to and it'll either come from Apple 8 if that's a compatible version or it'll come from Apple 8 next if needed which should be rare. We know that CentOS hyper skills also has it too. I'm looking at the chat Yes Robert, really three years Red Hat has publicly said we're on a three year major version cadence now and a six month minor version cadence. Another thing that I want to mention is probably some of you guys already know who maintain Fedora packages if they want to opt out from the mass build just because they want to handle depth solving by themselves they can add no auto build file in their district branch district repo under the branch and that will skip the rebuild of the package. So there's another question from Kushal for any third party repository for the next should we focus and build based on the Apple 8 next repo? It depends for I mentioned that most packages don't need to worry about Apple next at all. They can just build regular Apple packages and they'll install fine but if you do run into a case where there's a package dependency chain that's affected by a library change then you can target that also what I think would probably be best for third party repositories if they want to support CentOS stream it benefits them because it helps them prepare for the next major minor version of RHEL. I know of one major project so far that's doing that the open ZFS project they're running their CI against CentOS stream now because historically they have had long gaps after a RHEL minor version release where they were fixing their code to get everything to compile and work correctly now they'll be able to have that know ahead of time in fact they've actually helped us catch a kernel ABI regression that's been fixed before it made it into RHEL so everyone's benefiting all around but what I would recommend for things like LREPO and RP infusion if they can manage the maintenance of it run a regular repository and a next equivalent repository similar to how Apple has it and that they will correspond the same way and then have it where if you're just using RHEL you just use their main repository use the main repository and the next repository together just like Apple and Apple Next I'll also pitch like I did in the State of the Apple talk the previous one if you're curious about Apple and want to get involved we absolutely encourage it Apple Packagers are Fedora Packagers so if you're not a Fedora Packager yet I would talk to the join sig about becoming a Fedora Packager and getting a sponsor existing Fedora Packagers have a shorter road to it they can just start requesting Apple Branches and building for it and or Apple Next Branches we need all the help we can get as Ma said Apple is one of the most downloaded parts of the Fedora project but we have a lot fewer contributors than the rest of Fedora so it is not in a great state there and the more help we can get the more co-maintainers we can get the better so we can have good quality packages Yes, Matthew pointed out becoming a co-maintainer is a good route you can if there's a package you want to help maintain let's say it's an Apple and it's not being it's falling behind and not Bugsills aren't getting answered you can offer to become a co-maintainer to help fix a problem that you're having and that's also a good way to become a Packager in the first place and probably as Kushal mentioned it's the join sig that can help you with joining Fedora Packaging Company I was about to grab that too perfect we also have a new process now that's become really helpful called the Apple Stalled Packages process and if you open a Bugzilla asking another Fedora Packager to branch and build their package for Apple 8 if they don't respond there's a an escalation process you can do now you had to just do file an unresponsive maintainer initiate the unresponsive maintainer process in Fedora which results in every package from that maintainer coming under scrutiny and possibly being orphaned or assigned to you which is a very big hammer if you just need one Apple Package we decided we wanted to have a smaller hammer so what it is now is you can ask for an Apple 8 build and if you want to do it in a week remind them once if another week goes by with no response you can file a ticket to be added as a co-maintainer limited to the Apple branches of that package which will let you request Apple branches and build for them I believe that was Michelle that pushed that new process through and brought it to the steering committee as a good idea because it was running into this same problem so big big shout out and props to him Kushal your question the timeline should be increased because of COVID are you talking about unresponsive Apple maintainer timeline we are giving them two weeks I guess that's more than enough to just respond there's no punishment for that one that's just become a co-maintainer having co-maintenors added to your package is not a bad thing it is a good thing that we want to encourage unlike the unresponsive maintainer and we are not removing the maintainer as well from maintaining the package we are just adding the requested to become a co-maintainer right the unresponsive maintainer process like I said that's a bigger hammer than a lot of people are hesitant to pool you know people take vacation people are busy family things COVID someone could be in the hospital there's all sorts of things there and that's all that is addressed in the Fedora unresponsive maintainer process it's a lot longer process and it has further steps about trying to get in touch with the maintainer to see if they're even active in the Fedora project and even in open source in general trying to get a hold of them the problem is it's just too much for just I need this one package in Apple I'm not trying to take over your package I'm not trying to orphan your other packages I just want to help you maintain this and solve the problem I'm trying to solve there is a question from Robert not directly Apple next related but are there plans for more badges related to Apple next contributions currently there isn't but I like the idea maybe we need to talk to the badges team and create badges for next contributions absolutely I'd like to see that as well though I submitted a badge idea for similar to how we have a badge for serving on the Fedora council I propose a badge for serving on the Apple steering committee hasn't seen much progress yet but I know everyone was busy leading up here to Ness so I'm not going to fault anyone for that I'm hoping to get feedback from the design team on some of our ideas for that for that badge but absolutely any badges related to Apple that we don't there are already a few badges for Apple I believe they're related to number of updates submitted in Bodie is the main thing any other ideas you have around Apple or Apple next for contributions to get badges by all means submit them you'll have my thumbs up from it for for it I'm just looking at what Murray shared what badges that only if by the response I am the Apple steering committee this fantastic art provisional artwork is something that Troy Troy came up with some of the other badges focus for Apple focus on ants and ties the idea is that we're corporate drones because we care about putting stuff in Apple and eyes relate to business in the same thing open for other suggestions there as well well I say you go ahead and call it until the next talk give people a quick chance for bathroom break or water break thanks everyone for joining and we'll see you in the other talks come chat with us in pound Apple on Lavera IRC thank you everyone