 Today we have Martin crafts with I talk about packaging with version control systems I have to ask you to please when you're going to ask a question Let the Microphone reach you before you start look at the camera and say your name. Okay. Thank you. No Thanks So welcome to y'all. I Had a lot of fun preparing these slides in the last two hours As a matter of fact, I didn't spend all of these two hours on Slides only but there is a live demonstration that is going to be part of this. Don't worry. I didn't prepare it It's all going to be impromptu But I had to work with upstream to fix some of the bugs in the package that I'm going to be talking about or introducing And I love that pressure and he likes the fact that I'm talking about his tool now So I'm talking today about how we use or how we could use version control systems and specifically modern version control systems with that I mean distributed version control systems for packaging within Debian and actually I am interested in approaching this entire Endeavour or this challenge with a cross-distro Goal Because I don't think that well, let me bring up the next slide because that's my point of the next slide If we look at what the task of package maintenance is then we basically have Debianization of the upstream tree we create a package. We upload that package people start using it. We get bugs We also start to develop new features and I make distinctions here between features or bug fixes Which are there? There are three classes of them. The first one is distro specific ones Then you might have something like package format specific ones For instance, the entire Debian tree is shared by all other Debian derivatives And that's so that's a specific change that is made for depth packages, which RPM packages don't have Whereas RPM packages might add the spec file and then we also have features that are intended for upstream Bug fixes and stuff which is best pushed upstream so that everybody in the world can profit from it Once we have these new features then upstream is going to release a new version at one point in time And our task is to keep track of which of these Features have been merged by upstream which of these features upstream hasn't accepted yet and also of course adjust our Package and all the specific features that we have developed for the new code If you look at this list then I'm sorry. This is so far down. I hope you can still read it If you look at this list then the only thing that is actually distro specific on this page is Debianizing the upstream source stream number one and I guess, you know, you could have I could have called that differently, but What I want to Get at is the fact that package maintenance is basically the same across all distros at least all distros that use a package format which includes files that are installed on the system So with this in mind, I Thought about how we could facilitate the operation cooperation between different distros is very much Motivated by my own involvement with the MD ADM rate manager where Ubuntu and SUSE and Fedora are doing really good work And I'm having problem keeping up with what they're doing and they are probably having problem keeping up with What I'm doing and I have problems with users that approach me and say hey aren't you the MD ADM guy? Help me fix this problem on my fedora system And I have no idea how they do things there because they do things differently So I would really like to have a package maintained across all the distribution so that all of our users are basically using the Same package the same software and all these distro specific Changes are kept to an absolute minimum We as in Debian and also Fedora and a lot of other distributions already claim or live by The claim that we push whatever we can upstream So that we don't have to maintain those things Ourselves and that all the other distributions can get can profit of it But we all know that this isn't true in all cases We have some packages that have diffs that are a couple of megabytes in size or add a thousand packages to them Gdpc anyone or you know a couple of other packages that are very complex and upstream is just not interested in the patches or the cooperation between upstream and the Debian developer in this case isn't optimal Possibly because upstream uses a different way of managing the source tree Then the Debian developer and so there is no easy way of exchanging patches every single time You want to send a patch upstream you first have to create it paste it into an email get it Integrated upstream and then when in when upstream Responds or integrates it then you have to make sure that you remove the patch locally And well any of you who has have previously worked with distributed version control systems will think hey That's exactly what the distributed version control systems are best at tracking patches So if we can integrate the different players in this field for package maintenance including upstream into one Entity into one repository, then it's going to be a lot easier for us to exchange features and information so with that in mind I created Vcs dash pkg org Which is an endeavor that is cross distro. So I purposely invite That's why I bought a domain name actually didn't host it on alias.debian.org because I it's still a hosted there But it's not the domain name on there. I invite people from other distros to join and we have a lot of fedora people on There already and we have went to people on there, and well, I hope that this talk is going to possibly Get some other interested parties to join us An important thing here is also that this is a VCS independent approach I think many of you will know that I'm personally a git user and a lot of you have very strong opinions about Your own version control system and that it's a lot better than everything else that ever existed on the planet Well, I don't care. I think if I look at the current players in the field of modern version control systems Of which there are git mercurial bizarre Maybe one or the other that I just left out The feature set is pretty much the same across them and with that I don't mean that they feel the same but that the same things are possible with them So they all can track your patches and they don't get confused if you do merges and here and there and everywhere They just don't get confused. They're good with that stuff So VCS package org with these two Specifications in mind that it's cross distro and VCS independent is an endeavor to determine a packaging workflow which accounts for everyone involved in Distro packaging and that is all the distros and all the packages for these distros I think I left out upstream on this one, but I'd like to have upstream in the list as well Also, every distro will have QA release security teams and other Contributors who have to look at a package without actively maintaining it all the time so they should be able to Easily use any workflow or infrastructure that we put in place And the goal is to enable all the distros to work together On a version control level system on a version control level. Sorry There are many other endeavors out there that try to pull together Distros and make them work better together launchpad is a very good example which Works on communication as far as I understood and also has version control integrated But I think the primary goal of launchpad is to ease the flow of Information and communication between different players in the field VCS, there's also a Mating list distributions at free desktop org. Is it free desktop org? I think it is where a Couple of people are actively trying to pull together and make make decisions Not on a per distro basis, but all together. So recently there was a discussion there about what to do when upstream provides File names that are too generic how do different distros handle it and hopefully I haven't actually followed the thread But hopefully they came up with a solution that can be then be adopted and is acceptable to all the distros so that there's some sort Of uniformity between the distributions VCS package org Existed slightly before the distributions mailing list. I see that's not true It's existed slightly before the distributions mailing list started to get traffic Or a lot of traffic and we decided actually to keep it separate because VCS package org is Very technical on the version control level only it doesn't attack other Layers of cooperation at this point in time. So this is only version control Here's what I'm going to talk about today I'm going to give you a brief very very brief introduction into what's been happening in the field of Debian after all This is Debcon if I shouldn't be talking independently all the time An introduction into the new Debian source package formats that have cropped up and which have yielded Amazing amounts of traffic on our mailing list. So hands up to those people who haven't followed everything that has been said Yeah, but I'll summarize it for you. I'm just kidding Once you have these formats, I'm going to show you a Debian workflow Packaging workflow that uses git my packaging workflow But I think it's generic enough and then we'll talk a bit a little bit about where we should go from here So here the Debian source packages version 3 Work done by Raphael Herzog and a lot of other people who were involved with the package who basically said that our old source package format which is the DSC file an auric tar ball and a diff is Largely antiquated and if only for the reason that many packages nowadays use patch management systems within them the patch quilt whatever there is and So you effectively have an auric tar ball and then a diff which adds Diffs into the source package unpacked and if you try to figure out from the diff what is actually going on you'll have a Two-layer patch inside there and it's very confusing. I always get confused, especially when you start making changes to the diff directly It's very fun. So a couple of ideas have sprung up and I think the first one was Joey Joey Hess who came up with the idea. Hey, you know, we're all using version control systems At least we're using version control systems for the complicated packages or because we're you know, yak shaving as Like to call it. So, why don't we just take the git repository and make that our source package and there was some work on that and integrated into d package and it works and Shortly afterwards very very shortly afterwards. There was a bizarre equivalent of that So by that point in time We had two different source package formats that each stored the repository directly And if you would unpack it to source package the repository would simply be checked out And you'd have it available right there including the entire history of the package ever made with all the tags and everything sounds good A lot of people didn't like that. So we also had another one that was quilt. I'll introduce that in just a second Let me give you briefly Some of the arguments that were brought up against the VCS source packages skid and bizarre One of them was that we would now have to install new tools on the build demons And we would have to expect from everyone who wanted to deal with packages to now have git or bzr Install installed as well. So we would actually have to add them to build essential basically and you know And Debbie and people don't like adding things to core packages or base systems. So we prefer not to do that This is a related argument People didn't want to learn git or bzr or whatever was being used for each package because that's just another thing to learn Another thing keeping them from doing the work. They actually would like to be doing and then an interesting point was brought up by one of the people who's actually a well Pierre Habusa to is one of the Strong git proponents who then at one point in time started to say I think it's a extraordinarily bad idea to have source packages based in git and Mainly because it's based it would introduce dependencies on Third-party tools which are young We don't actually know whether in ten years git is still going to be around and backwards compatible Like tar or or are are what we're using currently Maybe git is going to change completely Then we're screwed because then our entire source archive our FTP Debbie and org is based on an outdated version of git and would basically have to for it and continue maintenance I don't think anybody wants to do that. So these were some of the arguments brought up against it And it seems to me correct me if I'm wrong that the quilt source package format is the winner in version 3 Formats simply because it's that tries to stay away From the version control systems from the younger ones and uses quilt which is slightly older But it's also way less complicated and it's actually not a tool per se, but rather a format definition It's really just a way of expressing a patch series So with the weekend pen format, which is was it was called previously It is now called the v3 quilt format We get rid of the diff GZ files completely. I'm very happy about that and instead We introduce a an additional set of tar balls the Debian tar tar GZ file Which when you unpack it into the source tree will provide your Debian directory and then you can also Install other upstream features into feature sub-directories and then use them obviously from your Debian rules file This source package format encourages the use of Debian patches Because you cannot make changes directly to upstream anymore with this You have to actually introduce your changes as a patch file under Debian patches, which is then applied during the build process and unapplied during the clean process Which is what many quilt and deep package at deep patch using packages already do The difference now is that this is deep package source Which is going to take care of it for you So you don't have to include deep patch and quilt rules anymore in your Debian rules file It will actually be done by deep package source and is assumed to work And I think that's a very great step forward Are there any questions so far before I move on? This was the brief summary of the millions of males that have been exchanged Any questions comments none All right I'll move on then and I'll start talking about how I package Debian packages with git I would should say I would like to package Debian packages with git because I Use this workflow for one of the packages and then I find out that it doesn't work very well So the next package I convert uses a new workflow and I currently have I don't know eight different git using workflows for my packages and I'm Having difficulty keeping track, but this one is the latest incarnation of it. So I hope it's going to make sense It is and let me say this upfront two things up front. It is a rather complex workflow I hate it myself at the moment because it always keep requires you to keep track of Exactly what's going on and you have to really understand git and you have to understand how the the history graph Is is Structured in order to be able to deal with it I will I hope it will become clear later why I'm still doing it and why I'm still pushing in that direction a hint is a wrapper that Simplifies this I would also like to say that even though I'm a git This is really version control system agnostic I don't know of any of the features that I use in this workflow, which are specific to git So whether you use mercurial or whether you use BZR You can use the same workflow if you want. I Use a lot of branches. I Have an upstream branch which tracks upstream or to which I import new Tar balls whenever upstream releases something I also have for some packages specifically those that have autoconf a Specific branch where I store all the files that autoconf generates because what is in the repository is not what you get in the Tar ball and because I also use Joey has his pristine tar tool I want I need to be able to have the exact same content in The repository as is in the tar ball pristine tar for those who don't know what it is is basically a binary diff which takes the content from your repository Fuses it with some metadata. It's stored at the time We need to commit it a tar ball and then recreates the tar ball that you previously committed in such a way that all the timestamps are Identical and the MD5 sum of the tar ball is identical So you can see the benefit here I can have my tar balls stored directly in the repository and Anybody checking out the repository can recreate the tar balls the exact same tar balls that are at the basis of the source packages Which we uploaded to the archive I Have features namespace so and get you can easily do slash which is sort of hierarchical Branches, but it's really just another character. It doesn't matter. You can use dash. You can use dot whatever you want features for Changes that I made which are targeted upstream. I have debian specific changes. I Have the main debianization branch which basically contains the debian directory and the control files And then there is also a build branch which I used to integrate and to build The features of this workflow the reasons why I'm still sticking with this even though I think it's Master is probably debian. Yeah And the question was whether I don't have a why I don't have a master branch, which is the default and get well In part because I didn't write this with get in mind This is written like on a on a conceptual level and then you can make whatever you want the master It doesn't have to be a master even you know, it's just naming convention So the main debianization branch is usually what I have as a master So the reasons why I still stick with this even though it's pretty complex is because I can Maintain and develop features independently. If you don't know the benefits of this, please go and talk to my not and Bring some time with you. The repository Contains everything that I need to recreate the original source package that I uploaded This is largely work done by Joey Hess on pristine tar and also My workflow even though it is it uses version control on my side the source package that I generate is a v3 quilt compatible one So it will actually export all the changes that I made all the features and all the debian specific changes To patch files into a quilt series which get then later applied to the package on unpack The benefit of this and there was a lot of discussion here as well on the mailing list The benefit of this is simply that when you get the package when you unpack the source package You it's much easier for you as a contributor If you don't know the code to see exactly what the changes are that are being made rather than get a 200 Kilobyte diff file and have to figure out which Changes belong to which features you actually get all the features nicely separated in the patch series So for a long time, I couldn't actually use this or well I couldn't use my workflow while I had to look at Pierre Habusa using his workflow Which is admittedly a lot simpler but targeted for the for this creation of the quilt series because until Eight days ago. We didn't have top kit Top kit is basically a patch queue manager for git. It is uses an entire branch for a patch so This is possibly a little bit confusing because a branch already has patches on it Well, it doesn't the branch has commits on it But the entire branch the length of the branch from master to its tip is what will be the patch that you send upstream If this is an upstream feature branch for instance So it uses one branch for each patch many commits on each branch it completely allow it allows you to introduce any form of dependencies between The patches so you can have any patch depend on any number of other patches and Not just as is the case with the quilt series one patch It's not a stack or a queue however you want to think about it It is really a directed acyclic graph that you can create Later than if you want to create the quilt series then obviously this just does a topological sort on the graph and squashes it down into a linear series And that's what you get It allows unlike previous tools that existed stgit for instance This allows the use of all the git features including the index and also is fully distributed So you can push stuff out and work with other people and have exactly the same top-git managed feature branches Between the different repositories and as I said earlier This is not something that is git specific as a matter of fact it was the last one to join this party Bazaar has looms and mercurial has I think they're called patch cues. I wasn't entirely sure about the naming of this They have some of them may not have all the features that the others have but I think there is a strong trend with all the version control, but maybe except the git ones to to Provide the same functionality that the others have git sort of looks forward only and that's not a good thing Where's bazaar and mercurial tend to try to include good features that they have somewhere else Their version control systems and git is a fast system used to manage to Linux kernel only right? unfortunately So this is ah That didn't work out at all this is the big picture and I have to Say that this is not entirely up to date. I apologize for that, but I didn't have the time anymore to do it But just to give you a general feel of what's going on So we have the upstream branch That's the long-living branch where we import tar balls or what we track for upstream We have a branch off that with the upstream patches the ones that are intended to go into upstream We have the master or Debian branch going down there and then off the master branch We also have a couple of feature branches, which are merged back into master I don't know if you have to do that with other version control systems Git requires you to do the merging back rather than to keep them running in parallel because git is actually very stupid and Then when you make a release you have a build branch and into the build branch you merge all the other branches well specifically the the upstream patches and the Debian branch and then you build the package from there and you Tag it and you're done when the new upstream release comes along. I Don't actually have I do have that over there you merge it into your feature branches and you do your changes and You re-merge all the branches back into the build branch build and tag and you're done This was previously very very difficult because there was no tool that could help you keep track of which branches needed to merging which branches could just be fast-forwarded basically and Where the actual conflicts would arise so you'd have to do a million steps if you had ten feature branches It's something like you know ten plus two steps or something that you'd have to do on the command line Just in order to be able to create a new package. I Stuck with it. I think it's a good workflow, but but for other reasons not because I'm a masochist or anything of that sort So I didn't prepare anything here, but I'm willing to try to show you this in action on a very simple package I think we have enough time to do so. Is there a general interest to see some hacking? Is there anyone against it? Are there any questions before I start? All right Last time I did this was at LCA and I swore never to do live demos again that aren't prepared, but you know So be it Is this gonna be is this large enough? Can you read this? All right, so I'm just switching to a temporary directory here And I'm going to pretend that this is my upstream and upstream is an Ingenious package that has two files which are empty and I just have a little bit of aliases here that check them in so basically now I have a Let me just bring up a good K quickly to make it easier for you guys to follow So now I basically just have Uninitial check-in. This is upstream with its two ingenious files So I want to create a Debian package out of this So I branch from upstream If there's anything that I do which is what you think is get specific Then please tell me because I would like to know whether it actually is I think it isn't but we'll see so Yeah, except I can't Unless somebody can tell me off the top of their head what a larger font is dear who wrote this Yeah, I don't have that installed either There must be a way to do it give me a second What's a large font does that exist that's not larger I'm sorry about this should be able to do what All right, I'm sure you love watching this As much as I love doing it That should be a little better. Is there is that better for the people on our team? all right, I Can use the confusion to quickly rename my master branch to upstream and Now we're back to this point We have upstream with its two files and I would like to debianize this package so I am going to branch off the tip with my debian or master branch and Create the debian directory with The debian control file in there and they've been rules and so on and so forth So I add this file and I commit and now I have a Branch off upstream basically now. Let's pretend that we are actually making changes to upstream Let's pretend that upstream didn't have a man page. So we are going to create a man page I wish man page writing was as easy as touch every single time Now of course the problem is that I'm currently on the debian branch. So I should actually be doing this on another branch so Before I check this in I Will create a new branch which I call feature man page And I will base it off upstream and now when this branch I can check in my man page Except I'm not using topkit at the moment Sorry, give me one second Yeah, so now I can use topkit to create a branch which is called feature man page Why don't you do this? There we go Sorry, so I now I created a topkit Feature branch and what you will see here is that topkit actually creates Two files in there one of them is called top depths which are the dependencies of this branch So in that file you will basically see that top This feature branch depends on upstream And you will also see top message and this is an interesting approach of top Git As a as a function of it using only one branch for patch or only one patch per branch this top message Actually is what you should be sending later on in your email to upstream or what you can export later on To the quill series So it's basically just the patch header where you're supposed to edit now and provide all this funky information And I'm just not going to do that So I'm going to add my man page now Where's where's Clint? Why does this not work? Said his age should really be auto completing this and I'm going to create my commit Which creates these three files now if I look back and at the tree Then you will see two things one of them is of course We have a new branch here, which is off upstream and includes the changes We have made to upstream the other interesting one is that we have a new namespace introduced here Which is called top basis feature slash man page This is top git internal obviously And it is used as you can maybe tell to create the patch that is between where This feature branch was based off and the current head. So the diff is basically between those two now Let's pretend I create another Debian specific one because one of the files is being installed into the wrong directory So I do tg create Debian specific one FHS Stuff and I base that off master now. So this is not an upstream specific one This is actually a Debian specific one. So I base that off my Debian branch Now you will see that it also creates these files obviously and it And I should be doing stuff to them But let's pretend for now that all I have to do in order to make it compatible with Debian is Add a file. I hope you don't mind if I simplify this, right? So I'm adding to see and I'm creating that commit Yep Yes, that's I had a slide earlier on about this It's just convention really so I put all the features that are targeted for upstream into the features namespace all right, so I'm adding see and That created the another top kid commit here and if I look at the graph Then you will see that we now have feature man page based of upstream with a base here and then There be an FHS based off master with a base here So far so good Now if I wanted to build this then I would Create a build branch off upstream and I would just merge all these branches that I have into that Branch as a matter of fact, I would export The patches files from top kid into that and merge the Debian branch So I'm going to show you how I do this first of all The first thing to do and this could also this could be done in in sort of one command with an octopus merge But I'm just going to do it separately now. I'm going to merge Debian into Master Into this so now we have the Debian control file right which is empty Now the next thing I want to do before I build is Export all the feature Features that I've just created into these top kid branches and I want to have them in the Debian patches directory So now I do The way top kid does this is by exporting or by flattening all the feature branches into yet another new branch That's going to be a temporary branch, which I only use to obtain the quilt series So this is two commands that I have to do in series. First of all I switch Back to for instance the features branch the man page and I do tg export of all the commits on This branch into my new temporary branch now if we look at the temporary branch then it basically just has One single commit, but that commit is not identical to this one It is actually the commit that represents the patch That belong that is Represented by this branch, so it's not exactly the same commit, but it's a squashed commit of all the Commits that have been on the on this branch, which is currently pretty uninteresting because we only have one commit on there But bear with me for a second So now I can use this temp branch to create with git format patch The series and I can do that by saying this is between upstream and head and I would like you to put all the patches into Debian patches All right now we have a file in Debian patches and that file is essentially just a patch and as a matter of fact It's more than a patch It is a quilt compatible patch. You can use exactly these patches with quilt Which is very nice So now that I have this file in Debian patches I Would actually add it to my build branch because it's part of the package that I'm building And from here on I built the package and I uploaded and I'm done now if this is clear to everyone then I would Like to skip the other feature branch that I had in there But actually move towards a new upstream release and see what happens to all the feature branches that we have created No voices against that All right The upstream branch we're back here. There's no Debian directory git doesn't track empty directory. So this directory was empty and it was left around I just removed it just to make it clear. We're back on the upstream branch And we have commits files A and B on here now upstream ingeniously decided to add a new file I could make that see now, but that would that would cause me to do conflict resolution Which sure we can do that so this is a new upstream release and With that new upstream release sorry, I Now want to include all these changes in my master branch. So I merge Upstream into master and I actually don't get a conflict because git is smart enough to say an empty file equals an empty file There's no conflict Sorry, but I guess you've all seen conflict resolution and action. So I don't need to repeat that up here Now if we look at our graph again It gets a little complicated But basically what we have now is upstream used to be here that was the initial Commit, and then we have a line going up here to the new upstream So this is the new upstream version that is available here and we just simply merged that into master So master now has in its in in the source Directory not only the debianization changes that we have made but also the entire new source code for the new version of upstream and a lot of a lot of you have probably used at one point in time SVN build package and Maybe you've used it with this dreaded feature that would let you track only the debian directory and then would like do magic during build to obtain a tar ball and like fuse them together and Generally sure that's a good. It's a good approach because why would I have to actually track all of upstream's Files in my source repository again Upstream is already putting them somewhere the information would just be duplicated Like all I have to do is my debian directory and then I have to use debian patches as well So it's kind of nice, but if you actually want to make changes to upstream With this setup and every single time you want to make a change You have to do that merging yourself as far as I understand as we in build package never did that for you So you have to unpack the tar ball You have to check out or export your debian directory into that unpacked source tree And then make your changes create a patch move that patch back into that SVN check out and commit it and That's very error-prone So I personally and you may well have a different opinion on this I personally really like having the entire upstream source available in my debian specific repository First of all disk space is getting cheap second of all the version control systems are all doing Compression so you're not really losing that much space at all You at most one import basically all that the further changes are going to be highly compressed And then third of all well, you know if it makes your life easier then that's exactly what you should be doing You shouldn't be conserving space on your servers Just if that requires many more many more steps on your part So is there a question back there? Yes, I have a question from my RC from Eugenie Golob He's asking why your your patch the patch you created for debian included some hidden tissue files Which seemed like craft Okay The patch I created for debian this one if it did then Then I simply didn't recompile After this is one of the bugs that we fixed half an hour before the talk. Yeah This is true Yeah, if you look at the patch that was created and which is later exported into the debian patches directory That patch actually adds those top-get files. You can see it over there top depths and top message That it shouldn't do that and it doesn't do that anymore. There's already a fix upstream. I used an old version of TT Does that answer the question? I hope yeah, Zach So the question is I you skipped merging upstream in the feature branch, I guess Is it normal because the DG does some magic for you or? Yes, I don't actually I Only merged upstream into master at this point because master is a plain git branch Master you could just as well track Master as well as a top-get branch and I think it might be a good idea But I didn't come up with that half an hour or 15 minutes ago when I started this so it should possibly be that as well But I do not merge Upstream the new upstream version into my feature branches debian FHS and feature man pages because That is exactly what top-get does and I'm going to show you this if I check out If I want to keep track of what's going on currently then there's this lovely command called tg summary and Tg summary tells me about all the top-get branches that are available in the current tree And it also tells me with that D that they're basically out of date so that they have to be updated I Think this is a difference between the bizarre implementation of this Patch queue management. I don't know about mercurial at all and git because bizarre I think can be configured to do this automatically to do the updates automatically whenever there is a change happening on the base branch With git it never happens automatically. You always have to do it Specifically and I don't think you can even Maybe there's going to be a feature at one point in time as a matter of fact There is a hook that comes with tg which probably does this I haven't looked at that yet, but anyway, let me Just check out one of these branches and as you will notice and this is one of the features that I really really like about Top git is that I'm doing git checkout Debbie and FHS I'm not how I don't I don't have to use SG which was the ST git the stacked git implementation for everything I can actually use git as I've always have this is really just a thin layer on top of it So in this branch I just simply say tg update and what tg update does and I'm afraid this is not going to be a very spectacular Example because I simply don't I don't have the time to give you a complex Example what tg update does is it basically merges? As you can see here It forwards the base To the new version on which it is based So I did Debbie in FHS now, which isn't the upstream feature branch But it's a debbie in one but because I previously merged upstream into master Master now has a new version. So we actually have to forward the base on which this patch is supposed to be based To this new version and you can see here that the top basis Pointer ref pointer is now pointing to the new one and then obviously we had to Take this commit and merge it into this branch For the changes to be available there and at this point in time tg update when I run tg update And there would have been any changes incompatible changes between upstream and myself I would have had to had to do the conflict resolution and then commit but after the commit I know that my Patch is actually based on a new upstream release now I Almost said my patch is rebased to a new upstream release note how this doesn't use rebasing at all Rebasing is some people love this feature about git and other version control systems that implement it Some people hate it and I think it's largely It's badly misunderstood in many places. So you shouldn't be using it and it makes it impossible to cooperate Because it rewrites history and you can't rewrite history in two places at the same time So it makes it impossible to cooperate top. It doesn't use any rebasing. It just uses merging So I think I'm going to run out of time unless I move on now Find me at the conference if you want a better demonstration of this or just Play with it yourself There will there's a link on the VCN package homepage to top git But let me unless there are any questions at the moment Doesn't look like it Then let me move on because I have one other Thing on my agenda, which is basically back to VCS package org and where are we going to go from here? What you saw right now was git used for Debian packaging, which is what I do But I hope you didn't see was anything that was very specific to either git or Debian I think everything that I did Can be done with the other version control systems And also I think if if you're willing to accept that creating Debian control is and Debian rules And so on it's pretty much the same as if you had just created an RPM spec file There was also nothing Debian specific and what I just did So where do we go from here? I Want to be working with other distros. I want to use for my packages The same repository as the poor dude at Fedora or a Wuntu who has to be maintaining MDADM Lovely package never make friends with it So how can we do that? Obviously, I could take the lead and I could just say look guys This is so much better than you guys and argue them to death And I hope that they jump on but hey, this is definitely not going to work or I Could try to work with them figure out how they do it and Whether they are overlaps and whether there are ways in which we can merge the ways that they do it With the way that I like to do things So Remembering all the branches that I was using Let's just add a couple of new namespaces. Let's just add distro for all the changes that are Shared by all distros, but which aren't going to be accepted by upstream for whatever reason LSB whatever it is This is also optional. We don't have to have this level of complexity, but we could Then maybe we want to rpm rpm and depth specific package format specific changes We'll put them in this namespace and we can have namespaces for every single distro that works on this with us as well And now if you've been following this presentation, then you have about 16 different branches and branch namespaces And you may just as well be wondering like I am continuously wondering whenever I work on my packages What do these mean? How do I work with them? And how do I how the heck do I stay on top of all these different branches? Well, I think the way that we can make this happen the way that we can use a workflow that is even complex like this is by writing a wrapper and I'm not talking about something like mr. Joey has this tool which Goes and looks at your current working directory and figures out whether it's git or bazaar or SVN and then translates the Commit command into whatever is appropriate for that version control system. No, I'm talking about a wrapper that actually maps What you're doing? Not what you would like a version control system to do. I think We don't need to be using version control systems per se to Use our or maintain our packages I think what we really want is an automated system that keeps track of patches Which has a history which we can use to inspect and find bugs and bisect Which we use to maintain packages and Fix bugs and interact with other systems. So I'm talking about a higher level command where you can say something like My wrapper fix bug give it a number and it'll automatically create for you a feature branch Invite you to make your changes there stole it feature branch away do whatever it needs to do with topgit or whatever else and Then mark it off in the bug checking system is done and create a link between that commit and the buck truck record So I think the way that we should go about this and the way that I'm trying to go about this is that we should And I've already started this talk to other distros Try to figure out how they do stuff map out the requirements and figure out whether we can actually merge all of this into a workflow Which We design all together obviously because everybody has to have something to say which works for everyone This is possibly a very ambitious goal possibly. It's impossible on the other hand I don't think it is right now call me naive or anything But maybe it is possible and I think it is definitely worth to try to pursue it try it out on a couple of packages By power users those people that are not afraid to deal with 14 different namespaces of branches Until you have a point where you refine it enough and you can provide this wrapper, which is VCS agnostic and which is actually Not only VCS independent but agnostic it doesn't do version control anymore It does packaging with all the good things that we know from version control and have learned to love Integrated well, and then as a last step once we have that I think Linux can definitely Compete a lot better because we have a lot of workforce out there and we're doing a lot of stuff Multiple times and we shouldn't be doing that So that completes my talk and this is completely outdated this page Thank you very much for your attention Vcs-pkg.org is the home page if you're interested in this it has all the other links so ignore what's what I've written there Thanks