 So specifically, we're going to cover what is arbitrary branching, why was arbitrary branching implemented, what tooling changes took place, and how to get an arbitrary branch. So basically, an arbitrary branch is just a branch that has service levels not tied to a Fedora release. So what I mean by service levels is take for instance, if you want to package something for Fedora 26, you have an F26 branch in diskit, you package it up. But it's also, it's implied that you're going to provide security and bug fixes that are released upstream and you're going to release those as well for the remainder of the life of Fedora 26. So basically, an EOL of 13 months there. So an arbitrary branch would usually have a service level that maps to the service levels provided for that version upstream that you're shipping rather than a Fedora release. So usually, the naming scheme, it could be anything, but usually you would map it to something upstream like a version number, but you could literally name it anything. So here are the current service levels that we have defined in Fedora and these will be managed later on by a real edge. So right now we have bug fixes, security fixes, stable API, and raw hide. Current Fedora releases have bug fixes and security fixes tied to their branches. EOL-7 and EOL-6 have an additional one of stable API. And then raw hide is only used that's tied to the master branch and it may seem counter-intuitive to have a service level called raw hide, but it's really just a service level that guarantees no service. Yes? It does not, no. So why do we implement this? The main reason is that it's beneficial to modularity. So straight from the Wiki page we can see that modularity is an on-billing initiative to resolve the issue of divergent, occasionally conflicting life cycles of different components. So you can't really achieve those results by just having one branch per Fedora release. For instance, if you wanted to have both the version of Python, Django, 1.9 and 1.10 in a single Fedora release, it would be problematic because there could be some incompatibilities with them. But additionally, perhaps one version of Python Django relies on a newer version of Python requests than the current distro is relying on. So this example here is one that I took from Ralph's presentation from DevCon. And you have the 1.9 branch on the Django module that relies on the 1.9 branch of Python Django and the 2.12 branch of Python requests. But let's say 1.10 does actually need that newer version of Python requests. It can use the master branch. I wouldn't recommend necessarily using the master branch other than testing because there is no service level tie to it, but you could for testing. And then using the 1.10 branch for Python Django. So it gives you this added flexibility to have those different life cycles and often conflicting life cycles without breaking the entire distribution because many packages rely on other packages and if you introduce a break and change, it could break other packages. The other benefit which won't be readily apparent right now is that once Fedora moves to be an entirely modular distribution, you can lower the amount of branches that you have to maintain. So for instance, I have a package right now that I shipped for F.25, F.26, and F.07, but also maintain the F.27 branch and master branch to make sure that they can always still build. In theory, this could be narrowed down to just one branch because there's really no differences between the branches. It's all the same spec file. So there have been a lot of tooling changes that took place to make this a reality. We primarily had two architectural decisions to choose from. It was kind of a challenge because we needed to support arbitrary branching in this new way of branching, but also support the old way as well because arbitrary branches are just used for modules and Fedora is not going to be entirely modular for quite some time. So we could have went and modified package GB to support arbitrary branching. This would have required significant modification to package GB, though, because package GB was written with the paradigm to map one branch to a single Fedora release. The alternative option, though, is to join up with Pagger Overdisk efforts and supplement it with additional APIs to Pagger, PDC APIs, and whatever scripting changes that needed to happen to support this change. So we ended up going with option two primarily because we thought it would be an opportunity to reduce technical debt for the future because if we're to modify package GB and make it work with arbitrary branches, but later on Pagger Overdisk project took off, they'd have to either significantly modify package GB again because there are some conflicting features between the two such as ACL management or you'd have to do some hackery where you have one sync the other. So in the end package GB would have probably ended up being decommissioned anyways, so it's saving some effort for the future. And additionally Pagger Overdisk does provide some additional features that are quite nice such as being able to fork and provide for requests on spec files. So this is what Pagger Overdisk it looks like. It's very similar to Pagger.io if you've used that. The primary difference is just a few seeming changes there, but I'll sort of walk you through the interface. I know it's a little hard to see, but this is a package that I maintain, Federico-REC, and on the right hand side are the maintainers of this specific package here. So I'm the main admin which is basically given to the person who has the repository created. There's not a whole lot of difference between a main admin and an admin, but Ralph here has commit access which means that he can contribute to all the branches, make changes, but he can actually invite other maintainers. In this instance I'm the only one that's able to do that. Now on the right hand side you can see the branches that are created on this project. So as I mentioned, we had to add some information in PEC, the product definition center. Some of it was new information that we had to add for arbitrary branches, but some of it is old information that package DB provided, but Pagger Overdisk did not. So this is a, it's hard to see, sorry about that, but this is a branch in an API that I wrote in PEC which represents the service levels that are tied to that branch. So it's the Apple 7 branch of Federico-REC, and you can see that there's the security fixes, bug fixes, and stable API service levels attached to it, each having an EOL set to 2024 June 30th, and this is our guess of when Ralph 7 would actually EOL. Down there there's the type, which is RPM, because these component branch entries can actually be from modules and containers as well, and the active flag there is a dynamic read-only flag is determined based on if there is a service level attached to the branch that has not EOL, then it's considered active, otherwise it is inactive, and the information that was provided in, stored in package DB that is not in Pagger Overdisk is whether that specific component is critical path or not. Just above the picture is the actual URL I used to query to find this specific component branch. So this ended up causing a lot of change, so the most notable thing probably is that there's a new tool now to request new repositories and new branches, and that's Federico-REC. I'll show some examples of how to request stuff using this, and also there's an admin tool that processes these requests that this tool makes. New branches in Git require PDC entries, so that PDC entry that I showed you there. Once that's created, the ACLs on Pagger get regenerated, and then it allows you to then create that branch in Git. I'm working on a PR right now to Pagger to have an API that just creates the branch for you, so you don't have to manually do this, because that is something that package DB used to provide, and that members of the community are interested in having back. Forking and pull requests, like I said, are now allowed, so no longer do you have to send patches over email or in bugzilla tickets. You can just for project, create a pull request, and have that discussion right in the pull request. And ACLs are now repository-wide. They used to be per branch, and this is a technical decision or limitation based on how you look at it with Pagger. Additionally, the ACLs are now handled through the Pagger user interface, as well as the watch status. So you used to be able to watch the bugzilla issues by selecting that in package DB. Now you just do the same thing but in Pagger, so there's a little watch button on the project to click Watch Issues, and it'll CC you on the bugzilla tickets that are filed against the project. Additionally, package DB would allow you to set the default assignee to bugzilla tickets on the product. So on Apple, for instance, if you wanted one of your maintainers to be the default assignee on Apple bugs, you would set that in package DB that's now in a YAML file and get repository and rel-enge-pador-sdm-request. Pretty simple syntax. The readme explains how to do that. And if you want to modify that, just fork it and submit a pull request. And additionally, the monitoring flag for the new hotness is set in that same YAML file, and I'll show you the syntax of that in a bit. But that's automatically filled in for you when you request the package, kind of like the way it was with package DB. Orphan packages are now denoted by the main admin of the project, being the Orphan user in Pagger. And retired packages still have that same owner as Orphan. But additionally, it means that all the branches in PDC tied to that project or that package are now inactive. So specifically, like how do I use this new tool? Like how do I request a new repo, a new branch? So it's pretty simple. You just DNF install Federico-REC. The latest version is in Fedora 26, but I'm still waiting on getting Karma for F25 and Apple 7. So if anyone wants to do that after the talk, please do so. So you just... It's basically the same sort of options that you had in the package DB ticket. And using all the defaults, you can create a new repository so Federico-REC, the repository name. So the project name that you're requesting and the bugzilla ticket that shows that was actually approved by Packager. Oh, yeah. It does not. It's a separate flag. So it'd be dash n and then modules or dash n container. It defaults to RPMs. Yes. And I think the bugzilla number you thought it was going to be used by? The bugzilla ticket ID. Yep. And does it verify that the... Yes. Yep. So when you actually submit a new request, it does some validation on the bugzilla ticket. All that it can. The admin tool does more validation because it requires a certain, like, authentication to fast, for instance, through the clears. So I'll show an example of what Federico-REC repo name, the first one, gives you. But I'll backtrack a little bit. This tool is basically a wrapper around submitting tickets using the Packager API. And it does a lot of validation. It just gets you the structure that the ticket needs to be in so that the admin tool can then process it later on. So the second option is just if you wanted to request an F26 branch for that same package, you would just do Federico-REC-branch, repository name and then the branch name. It's a separate command. But it comes with the same package. Yes. So if you want to be able to create a new branch it has to have the entry in PDC. So that's what gives you the ACLs to create that branch. So what this does is it actually creates the entry in PDC once it's processed. And then afterwards you can then create the branch yourself and get. But like I said, I'm working on changing the code so it creates the branch for you. So if you want an arbitrary branch, however, it's very similar to the command above except they have to provide service levels tied to it. When you're using just a standard Fedora release branch, we know what the service levels are because we know when the release EOLs. So we fill that in for you. So here you just type in so like say I have, there's a 2.1 version of a package upstream that's maintained until January 1st, 2020 and bug fixes and security fixes are provided. And I think that I can handle repackaging it when there's new releases of that version until then. Then I would set that EOL accordingly. So moving on. So I'll go back to the screenshot that I had at the beginning of the presentation. So this is the list that has to be from. It's defined in PDC and RelEng can add more if need be. But right now it's just security fixes, bug fixes, stable API and raw hide. Yes, but you have to submit a ticket to do so. Right, because it's a change in what you're promising to the community in a way. Probably extending it should probably be talked about as maybe being something that can be automatic. Yeah, but definitely shortening it would need some consideration from release engineering. So this is what a new repository request looks like in Pagger. It's just JSON. You never have to interact with this directly as long as you use the CLI tool. But in theory if you want to avoid using the CLI tool at all costs I guess you could just copy the JSON and modify the fields that you'd like. So the admin tool here most of you probably not use, but a few of you may. This is the list and it shows all the tickets that are currently in the queue. Right now I'm running the process 21 so I just want to process ticket number 21. I could do process all and process from oldest and newest. It then checks the validity of the bugzilla bug. Make sure that the project doesn't already exist. Make sure that there's an account and disk already for that. And then it presents the admin with the information about the request. If they wanted to further dig into it they could click on the bugzilla URL actually look at the bugzilla ticket and make sure it's okay. You hit approve. It creates the entry in PDC and maps the service levels to that branch in PDC. It creates the project in Pagger. And that sets the monitoring flag in the Bellinch-Vador SEM request repository in that YAML file. And it changes the main admin of the project to the request of the ticket because by default it's by the person who creates it. Adds comments to the Pagger issue as well as the bugzilla issue saying that was created with a link to it. And then at that point you're asked if you want to add an additional comment and then close the ticket. So processing that new repository request just gives you this bear project. You can see it's owned by Pierre. Just the master branch there creates the PDC entry with just the raw hide service level mapped to the branch. And that's the monitoring entry in the YAML file in Bellinch-Vador SEM request repository. So to summarize, arbitrary branches are branches that have service levels not tied to a Fedora release. They usually map to something upstream. Arbitrary branches are really made to enable modularity and add that flexibility that modularity promises. Pagger over disk it is the new interface to disk it and packaging requests are now done through Federico-Rack consider package. Any questions? We talked about it and we didn't come up with one. I guess... Yeah, exactly. We actually spent quite a few hours around the time at DevConf just discussing that and we couldn't find, come up with a good policy. So I guess try to make your names useful. Don't use profanity or copyrighted terms, but... Yeah. Yes. Yeah, it should not work and if it does, it is definitely a bug. Any other questions? Yeah. That's a good idea. Yeah, we could talk about it. That's a good idea. Okay. No, it's very important. Yeah, thank you. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. That's something we need to talk about, about gating because we don't, we don't want modules using like inactive branches, you know, components within them. So we want to have like gating that makes sure that if your service level on your module is a certain date that all your components within the module actually meet that level. Yeah. So there's a lot of things to consider about from the gating perspective through the module build service or some other service that, yeah. So we, yeah. So Ralph may know more about this but from what we've talked about is that we just wouldn't build any other new versions of it. Which is I think the right answer there but there could be discussions. Yeah. But I guess in a way if you're building a module for a specific Fedora release, the EOL is capped at the EOL of that Fedora release. Yeah. So, yes. I heard the rollout when I drew it this day went very smoothly. I did not bribe him. Yeah. Yeah. We, yeah, we do apologize or I apologize for that. It did not go as smoothly as we had hoped. I feel like we kind of overcame most of the bumps along the road more to come so please file issues and good issues. We'll try to fix them as soon as we can. Yeah. Yep. Yes. But the RPMs are only used in modules. Yes.