 Hello everyone, this short session, which window is this? Yes, this is the window. Let me introduce myself. My name is Funo Cimotani. I'm a software engineer at Red Hat, working with the packet team. You can find me all over the internet with the Nick Cimha and pretty much the same profile picture everywhere, hopefully. Today's session is going to be about using SourceGit to maintain packages, whereas then in Fedora, the agenda is kind of a short. First, I would like to do a quick walkthrough about what this kit is. So maybe I should ask if there is someone in the audience who is not familiar with this kit concept. You can write in the chat then. And then I would like to walk around a little bit of, yes. Yes, I don't know what that yes means. I would like to walk around the concept of SourceGit and then check a little bit out the tool in me and my team is developing, which is called packet. OK, so Frank is not familiar with this kit. So let's see what is this kit? Actually, for this presentation, I did a little bit of research or, I don't know, looking in the past. And on Fedora Wiki, I happened to find the original Disgit proposal, which was a change proposal to introduce this kit. This seemingly was somewhere in the end of 2009, December, maybe. And it turns out that back then, all Fedora packaging was happening within CVS, which some shared directories and people were really not happy with it. So this is how Disgit started. Basically, Disgit for Fedora is src.fedoraproject.org. And currently, it's running a peggar as the forge. And this is the place where all the packages, all the sources for all the packages are stored. Now, the reason we don't just call it, but there is this disk in the beginning, which, if I'm not wrong, it stands for distribution. It's because it has this somewhat weird layout. As you can see here in Firefox, for example, you are going to have all the patches which are distribution patches, like specific to Fedora. And then if you are going to scroll down at some point, where is it? Yeah, you are going to find the spec file in here plus all kinds of other files which are required to build this package. And then there is this weird little file, which is called Sources, which is having this format of specifying how to check the validity of this archive. And all these archives are stored in a place we call Lukasite Cache, and all these hashes will verify that the file retrieved from the Lukasite cache is really the one which was saved there. And then really what happens during the build process is the archive is downloaded, or these archives are downloaded from the Lukasite cache unpacked. Then all these patches, which are here and specified in the spec file, are applied on top of that tree. And then the build process can continue. Now collaboration in this format is a little bit strange. Maybe I'm wrong, but as far as I know, in previous versions when this git was running a pegger for top of it, some maintainers were even like directly pushing to branches, which is still possible. Since pegger, more and more people started using PRs for any changes. But because basically you store downstream patches as separate files in git. Reviewing such changes was a little bit interesting, because as you can see, for example, in this example, in a PR you are going to review patches of patches, which is kind of an indirection cognitive load, I would say. And it's more difficult to check, because basically you don't have the whole context of what in which these patches are happening. So this is where source git comes in. And I would like to say at the beginning that this isn't really a new thing that we just invent. While I was doing archeology in the Fedora wiki, I also found that, hello, Michael, you just missed what this git is about. So yeah, if you know that, then it's fine. Yeah, so I found this supposedly there was a source control management special interest group. And no problem. And they had an agenda. And this is also back somewhere in 2009 that can they have exploded three packages to work on? And this is what we did source git is. Source git is just you don't change the format of how you get sources from upstream. You don't create an archive and then upload to the local site cache. You just fork the upstream repo, like use git for what Linus invented. And you apply downstream or distributions changes as separate changes as commits on top of it. So it's like really just use git as it was intended. You have the upstream history and then just apply downstream patches as a separate branch. And what our team thinks and what proves to be the case, we really think that a source git layout can be a place for to do creative and interesting work and not needing to handle all these and in directions of what this git format requires. How would this work? Another diagram. One of the things or the way we work with source git is basically take upstream releases, which might be text or branches or whatever, pull them into your source git repository. You can create for each release a branch just for all the ability so that you can go back anytime and see what was the release. And then starting from this branch, apply the distribution patches or changes and then synchronize this branch and create the master branch. Which is going to be a high for each release you can do and create the corresponding branches. How would this live? We know that this part is SRC Fedora project running Pegger. This can be any kind of Gitforge, any kind of Git repository. And the source Git part, this is what you can really store pretty much anywhere. GitHub, GitLab, Pegger, BitKeeper, sorry for not putting in the slide, or really anything you would like to. And now some people might say who are doing packages that, wait, I'm already doing something like this. Yes, I said this is not a new invention. Actually, what we found, one of my teammates started the thread not long ago on Fedora Dev or regarding the subject. And what we learned from that thread is that many teams and many people are using something similar either locally or they even have their forks of upstream repositories somewhere in GitHub where they create their branches and use those branches to manage all the downstream patches they are working with. And what that really means for them is that they are able to open PRs which are more meaningful because you are actually looking at the code which you are patching and not looking at the patch which is going to patch your code. So I think that's a really nice thing to have. So yeah, this is not a new invention. What is somewhat new? And now let's have a look at tooling. The basic tooling, it will be Git. When you are working with this Git, yes, you are also using Git but then you are going to use some other tools. You need to use patch, right? Sometimes Jandive, things like that. One of the tool my team was working on is Packet. This is Package for Fedora. This should be really a command line tool which basically currently will help maintainers doing these things between their source Git repositories down to their Git repositories. Plus Packet also enables you to trigger some builds either in Koji or to test your packages. You could use a copper for that. But what is more important or interesting maybe is that we are working on a GitHub application. Basically, this is offering Packet as a service and what this application will offer you once you enable in your source Git repositories which you are storing in GitHub is that it will allow you to... It will give you some checks on your PRs in source Git. It will build your changes in copper and provide feedback as flags on these PRs. Plus, there is a possibility to test these builds using testing for. And it also supports proposing new releases to this Git. It will basically open you this Git PR in src.fedoraproject.org with all the changes you did in your source Git repository and then you can review that and merge it. This is currently a GitHub app but we are working on like Pager support is already done and GitLab support is in progress thanks to one of the guys from Google Summer of Code who is helping us with this. And this is really a call for the brave of you out there who would like to try this way of packaging out. So you could reach us on either check out our documentation on packet.dev or find us on GitHub or IRC. Cool, thank you for listening in in the name of the entire team. And let's see if there are any questions. Frank is asking, isn't just like rebasing downstream patches on top of upstream tree? Yes, many people do like that. Other people, other projects we've seen doing this Git will choose cherry picking or any other Git operation. So yeah, it's like rebasing downstream patches. I think the main difference is that this is permanent. You can share with others who you are packaging with. I hope I get the context right and it's not something like you do just locally on your machine actually lives out there and others can contribute.