 So, hi everybody, I'm Sahana Prasad. I work for the crypto team at Red Hat. I have helped co-maintain OpenSSL for about two years, both in Fedora and in REL. My topic for today is migration of OpenSSL from disk kit to source kit in Fedora, with the idea that downstream package maintenance could be a bit more easier. So we'll talk about what is disk kit, what are the shortcomings of disk kit, how do we address the shortcomings of disk kit using source kit, a tool called packet that would help us create a source kit repository. We'll define a workflow for development in source kit and we'll do a short demo at the end. So what is downstream package maintenance? While upstream open source communities create original source code, downstream is an entity that consumes this code, packages it, and distributes it into various Linux distributions. So what does a downstream maintainer do? A downstream maintainer packages and distributes it, this is the responsibility, into Fedora, REL, and CentOS. Downstream maintainer also adds downstream patches that could be feature requests from customers, security bugs, critical vulnerabilities, and so on, as downstream patches on top of source tar balls. Where are all these packages stored? These packages to be maintained are stored in a distribution git repository called disk kit. Disk kit is designed originally to hold RPM sources. So for every package the contents of disk kits are the following, there are downstream patches, there is a source file that points to the upstream tar ball, and there's a spec file that acts as a rulebook to govern how package maintaining should happen. It's important to note here that disk kit does not track the upstream source git history. It only tracks the files that we spoke about now. If we talk about OpenSSL in general, we have about 49 patches that we maintain downstream. So every time we did a new rebase to a newer release of upstream, we felt that a git rebase could have done a better job than manually changing multiple patches. And reviewing patches is also not a lot of fun, especially when you submit patches to a patch, you need to have the entire source code open to know the context and stuff like that. And most of our fixes in Fedora or in REL are direct cherry picks from the upstream source, but this git does not have room to accommodate for cherry picking. And in general, to create multiple patches for different releases across different distributions could really become cumbersome. Just the general idea is that code should not move around. There should be a tool to help us do this for us. So then we come to source git. I asked at GPT, could we address these concerns and can you define what a source git for me? And it said, sorry, unrecognized until 2021, I haven't been trained to answer this question. But really, source git is gaining a lot of importance over the few years. Packages like Kernel, Python, SystemD, and other packages have been using open source git for a while now. So what is source git? Source git on the other hand tracks upstream source history. You can consider it as equivalent to disk it, except that instead of source star balls, we directly work with upstream source files. And instead of downstream patches, you apply them as git commits on top of your upstream source code. So it maintains upstream git history. It could be treated as an add-on to disk it in day-to-day use for package maintenance. And to see how a source git repository works, each package can have its own rules. And here we're looking at a standard tool we could use to create one for us. So packet to our rescue, packet is an open source tool that helps us to easily configure a source git repository just with a few commands. So if you look at the source git init command, all you need to have prior to this is a fork or a clone of OpenSSL package from your Fedora diskit and directly have the source from OpenSSL upstream source repository. And it creates certain directories, first called the .distro directory, which will have all the files that were already in your disk git except the patches, because we don't work with patches in source git. Then you have a spec file that is tracked here and a source git yaml file, which has all the files that are to be copied to diskit. So we can also sync between source git and diskit. If you run this command, then whatever change you make on your source git repository directly reflects on the diskit repository. So now with the previous command, we created a source git repository. On top of that, you can add code, you can add a commit or you can cherry pick a commit. And after that you run this sync command and directly you get patches in your corresponding diskit and it's updated in the spec file. So to generally define a workflow of how we could use this in downstream maintenance, first you need to check out, you need to find out what is your latest release of the software you want in your source git repository, find that out and create a source git repo using packet and check if all the downstream stream patches were correctly applied as commits and there were no merge conflicts. And since in Fedora, we work with many releases like Rohide, F38, F37 and so on, you need similar branches also in your source git repository to track the same thing and to be in sync. So check out a branch in source git, make your changes, commit your changes and push this and create a pull request and configure packet to create one automatically. You could do this as well. And once you review a pull request in diskit, you can merge it and your done. The question for rebasing to newer upstream releases, there are slight modifications for the same. You will have your Rohide branch, treat that as a, add a tag to this Rohide branch called 3.0.8 because now you have a new Rohide which will track your new upstream release. And then cherry pick all of the commits that existed on your previous Rohide 3.0.8 version. Now you will face with a lot of changes. You will have to manually fix all the merge conflicts because you're rebasing to a newer version. You would have done the same using patches too. So fix that here. And then if you run a update command, you'll see the patches on diskit, but just be careful to use this upstream ref tag so that the git history is tracked from the latest version. In our case, the latest version, we want to put in Fedorize 3.1.1. And now let's look at a demo. Yeah, so on the right hand side, I have a clone from Fedora diskit. Right side acts as the diskit, left is the source kit. Open SSL I have Fedora, it's 3.0.8 like I mentioned. I'm opening the spec file and I'm seeing what's the last patch added. The numbers are not contiguous here, 100. Now I move to the source kit part. Here I've only checked out the upstream sources from open SSL. I'll create a new branch Rohide here. With the tag 3.0.8. Now I want to create a source kit repo, right? So I run this init command. So to this init command, you need to provide the tag. And two repositories, one is your source kit and one is your disk kit. Bear with me, this download part takes a few seconds. So at this step, we'd be expecting that all the downstream patches we had, we saw there were about 40, but named as 100. All of them just being rebased as commits on my latest source. So if you see the logs, it's a bit fast, but all the patches are being converted. You'll see the last line here, the rebase patches from diskitmaster. So if I go back to source, open SSL now, this is a source kit repository. So I should be seeing the dot distro repo here. So look at the open SSL file now. And here I see that no patches were there at all. You don't see any patches anymore. They're all, they all applied nicely as commits. So now I'll try to do a sync between two source kit and diskit. I was in the wrong directory, I'm gonna rerun it here. Yeah, so here it says open SSL is up to date with this. So basically my Fedora and source kit repo are in sync. That's expected because I was on 3.0.8 and it did not make any changes. On the right, I don't want this build, so I'm just gonna make a clean repo of that. Now let's actually make some change. Just choosing a random file here and trying to make a change. I'm going to activate the legacy section and I'll also make a change to the spec file. Gonna add these changes and make a commit of this. So this is the test commit I made. And below you'll see all the other commits from RPN build, which were all patches to commits conversion. So now I'll come back and run the sync, source kit, sync, update command. And our goal now is that this commit should get applied as a patch directly on diskit. So let's see if that happened. I'm gonna come back to diskit here. Check the git status. You'll see that 0042 test.patch was created and this is the new patch file. I'll look at the spec file to see if the version was changed, we jumped it up to three. So the patch is present. It got appended directly after 101 and the version got changed to three as well. So yeah, that's it. So we created a source kit repo and converted from source kit repo to diskit and having a patch. At this point, you'll only create a pull request in diskit and build your package and that's it. So this was under four minutes, we did this. So we could try it for different packages too in Fedora. We want to see how it works with OpenSSL for a few months and adopt the same workflow for REL and CentOS. Do we have any questions? So the question was, diskit will remain as it is and source kit will be used for day-to-day maintenance by developers and eventually would you move from each other? Yes, that's right, diskit will remain because there's a lot of tooling around diskit. Like if you see the Fedora update system or Koji builds, everything is defined around diskit, so we'll keep it. And for package maintenance for developers for day-to-day activity, we will use source kit because it's easier to work with this. And you just create a pull request when you need to and you can also have packet automate the process of creating this pull request for you. So when you do some change in source kit, it's directly related. You can see it directly in diskit. So there's not a lot of effort to move between the two. So also include the package from it basically. Just when you are ready to release and upload a new version of the package. So the question was if you have multiple changes, will you apply them at once in source kit or would you do that periodically? So I will have, I will make all the changes whenever I have a newer release in Fedora. Yes, you're welcome. Yes? I'm writing a new release and revamp the new version. So whenever you do that, do you get a new branch? For that or just a new branch and do some changes? How does it work? The question was what happens when you do a rebase to a newer release? How do you work with branches? Do you keep the name intact? So what we want to follow is you, whatever was existing as the version in this, I'll just take this example to make it clear, 3.0.8. So earlier it was just raw hide. When I want to rebase to another version, I'll rename this raw hide to add this suffix with this tag 3.0.8, so it becomes a different version. And to this version, I'll make that as a protected branch. And the latest version I want to rebase to, I'll treat that as raw hide. So that will be 3.1.1, so that will be the head. Does that answer your question? Are there any other questions? You mean source kit? The question was if source kit unpacks the tar ball and updates commits? Yes, that's what it does. It applies all the patches as a simple git apply, but it preserves the upstream history, right? So it applies easily. Okay, we're out of time. Thank you very much for being here.