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 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


Greetings. Oh, so. So, greetings. Welcome to our session on addressing the 7% problem. Today, we'll be talking about the frame project and the Carl ARL Marrakesh Treaty implementation project. My name is Victoria on from the University of Toronto, and I'm here today with Pascal Calarco from the University of Windsor, Catherine classic and the Association of Research Libraries, Bill Casdorf from Casdorf and Associates. Stephen Downey, the University of Illinois, and John Unsworth from the University of Virginia. And the Carl ARL pilot project implementation will be the first part of our presentation. So we're talking about the Marrakesh Treaty and the implementation of that treaty for accessibility and the full title of the Marrakesh Treaty is to facilitate access to published works for persons who are blind, visually impaired or otherwise print disabled. So it is the first users rights treaty. It's historical and it's important, and it's linked to the human rights in the in the Universal Declaration of Human Rights, and in the Convention of Rights for people with disabilities. The goal of the Marrakesh Treaty is to end the book famine to change the availability of accessible formats from 7% to 1%. So the Marrakesh Treaty is a WIPO treaty agreement and it has 80 signatory countries. It was passed in June 2013 in Marrakesh, Morocco, and it provides an exception to copyright for the benefit of people who are blind visually impaired, or otherwise print disabled. It's an international treaty, and each country must ratify it and set its own enabling legislation. So the Marrakesh Treaty was the 20th key nation to exceed to the Marrakesh Treaty, and that signatory allowed Marrakesh to come into force on September the 30, 2016, three months after Canada's accession. The USA ratified on May the 8, 2019, and we now have 2080 ratifications to date with 37 more in process. The Marrakesh Treaty provides a legal framework and it allows each country to develop its own enabling legislation, and all the national laws must comply with the requirements of the treaty. However, there's there are variations in the legislative language among all of the Marrakesh Treaty so there isn't one implementation. It's the same as any other one. It has optional articles and Canada added a commercial availability clause and a royalties clause to our legislation. The United States did not. So the Marrakesh Treaty Task Force is working with Canadian authorized entities, the Bibliothèque Nationale et Archive Bibliothèque et Archive Nationale de Québec, CELA, which is the Center for Equitable Library Access, and NELS, which is the National Network for Equitable Library Services. We're working with those entities to understand how the legislation is operationalized in their process and what is required for the international lending component. As authorized entities, they are nonprofit entities, and they provide education or information access and authorized entities include libraries and schools and other and other kinds of educational and information services. And we've also been the Task Force has been also conferring with legal experts in Canada and the United States on the implicated implications of the differences in our laws. So when we want to do this pilot project together, we have to figure out how the two laws two sets of laws are going to work together. And in Canada and in this with this project the commercial availability clause is providing a lot of complications for us so it's quite problematic in the implementation. And that is with the production of the materials part of it and the export limitations. In the United States they, there are, there are other barriers but not the same barriers. As I said every implementation is different. So in section 1201 of the US Copyright Act. That is a section that prevents the breaking of technological measures or digital locks to access copyrighted works. Central to the Marrakesh Treaty is the ability to break the locks to make an accessible copy. So in the US this is going to be handled by the rulemaking process. And every three years the register of copyright issues exemptions for breaking the technical, the technological protection measures or the digital locks. In this year's rulemaking, the register of copyrights modified section 1201 regulatory language to reflect the relevant sections in the US Copyright Act that implement the Marrakesh Treaty, that section 121 a the register concluded that without the proposed modifications print disabled individuals would be adversely affected in their ability to engage in the non infringing uses. The language, it says that it will expand the description of intended beneficiaries. And it will expand the copyrighted works covered to include literary works and previously published music works that have been fixed in the form of text or notation, and adjust the reference to a market price of a mainstream copy, and instead use the, the word of the price of an inaccessible copy. In this year, the register of copyrights renewed a rule allowing temporary, the temporary right to create accessible versions of motion pictures, and to be able to use assistive technologies for people who are blind, visually impaired or have disabilities. In this and previous rule makings the register of copyrights as acknowledged that technological protection measures interfere with the use of assistive technologies. And the register also acknowledged that there's a significant role of ebooks in improving accessibility for persons who are blind, visually impaired or print disabled. So the Carl ARL task force for the implementation of the Marrakesh Treaty kicked off in September 2020. And the pilot is a collaboration between the Canadian Association of Research Libraries and the Association of Research Libraries, on behalf of their member libraries. They have a collection of library research libraries in these associations in Canada and the United States, and they have a collective holding of 760 million print and electronic works. The pilot libraries are two American libraries research libraries Cornell University and the University of Florida, and two Canadian research libraries, York University, and bibliotheque as she has to get back. The leader of the work of the task force has put put together a policy a metadata systems and a beneficiary working group. And the goal is to implement the requesting and borrowing functions within each country to allow for cross border exchange, and then after the pilot is concluded to use the results of that pilot to recommend an implementation plan for Carl and area libraries. So the metadata working group began in this year in collecting sample records from each pilot library for each format. And we reviewed the mark format fields used per library and per format and then with that decided on what required fields we're going to use in in the pilot, what would be mandatory what would be mandatory if applicable, what would be recommended is optional, and the considerations are myriad we looked at controlled text and free text fields, multilingual provisions, and how each field would function with a mark the market edit software. So we'll decide on fields for the pilot and evaluate and recommend the fields for the broader implementation. So I'll turn it over to Pascal now for the systems part of the implementation and other considerations. Thanks, Victoria. So when we look at this project, one would think that this is fairly straightforward. It's not that much different from a traditional circulation or resource sharing. Perhaps with the only difference that in America catch fulfillment, the materials do not need to be returned to the library. Next slide. We can think of five high level areas of work in this implementation. We already talked about the metadata issues. There's also digitization workflows that we need to consider libraries have been digitizing works for, you know, a couple decades now. But we haven't typically been producing those things in EPUB format, which may be the preferred formats for integration with assistive technologies. There's a variety of approaches to discovery, you know, do we put all of the metadata records in one place like in WorldCat or Hottie Trust or the Internet Archive, or do we have these be a more distributed approach, or do we do something kind of hybrid. Also, with the digital repository, do we use a federated approach similar to DPLA, or have geographically defined territorial repositories in each country, or use each individual library as an endpoint for the digital item and then have shared metadata in a discovery layer above that. Finally, we have identity and access management issues, because we have to ensure that these DRM free versions of works are only available to beneficiaries. Next slide. These are some challenges and decision points we've identified to date, starting with wanting to understand the functional requirements of users of beneficiaries and their technology kind of ecosystem. We need to consider that this is going to scale across the globe eventually. And so we need to make sure that we have the lowest barriers for libraries to be able to implement this. I mentioned the variety of approaches with metadata and identity and access management and the repository for accessible works. You know, ideally we want to digitize a work once and then have that be added to the corpus that's available globally. Next slide. Speaking about the user needs, we have started to engage with CNIB, and we'll be talking to the National Library for the Blind, and also focus on our campuses at the pilot libraries. And these are some questions we're going to initially ask of the campus partners and advocates for those who have print disabilities, and this is the focus of our beneficiary working group. Next slide. We're going to talk about the discovery of accessibility works. You know, eventually this will scale to any, you know, public or academic library in North America and eventually any of the Marrakesh treaty countries. We want to make sure that these are all searchable and discoverable by all beneficiary users regardless of where they're located. And how do we bring these descriptions together best in a consolidated catalog from those contributing libraries. Storage and preservation of these texts is also of key consideration. So we need to do this within the context of digital preservation. The formats can change over time, as we know that these formats continue to develop. And also the basic level of bit integrity can be compromised. So we need things in place to look at that as well. Next slide. The place that we're going to start is with our four partner libraries. And so we have recommendations for revising mark templates in each of those libraries will implement those templates in the four libraries. We'll probably create local creation or local location codes in each of the library services platforms that we have. And we'll create a either local or shared repository to store those texts in will probably create a new patron group for Marrakesh beneficiaries and allow only beneficiaries to be able to access that location and that underlying repository. And then we'll start with library to library fulfillment requests similar to the ILL workflows that we currently do. We recognize that eventually, of course we want direct patron discovery and delivery of all of these. So we're learning from other projects, including the frame project here and others in this work where I mentioned we're going to talk to campus accessibility officers and then also liais with beneficiary advocacy groups. Next slide. This is the list of people who are on the task force, and we have a central email address where you can get in touch with us. We'd love to hear your thoughts and invite you to help us out with this project. That's the last slide for our project. I'll now turn it over to Bill to start with theirs. Thank you very much. Let me get my screen share going here. All right, there we go. So I'm, I'm Bill Kasdorf I'm a publishing technology consultant and I do a lot of work in editorial production workflows with a big focus on accessibility. I do a lot of standards work. Most relevant in this context are the World Wide Web Consortium I'm publishing, Global Publishing Evangelist for the WPC and NISO. Let me get to full screen here. So the image that I'm showing on this slide is a picture of a woman looking shocked and saying what you just did all that work remediating that book and you can't share it. Well, I have to say I could have used a picture of John Unsworth here instead, because that's really the origin of the frame project he was a professor at Brandeis at the time, had a blind student was majoring in film. And so they had to create what are called audio descriptions. It's a confusing name because it's a description of the video aspect of the movie. You can imagine how much work is involved in doing that and at the, at the end of all that work, he discovered that those audio descriptions would not get shared.  It turns out that it's, it's still to this day very common that the disability services offices that are commonly called DSOs. These are the people that take a resource asset that's inaccessible to a given student and fix it basically, which is called remediation. For example, doing, making those audio descriptions or putting image descriptions in for images or tagging a PDF, etc. And it's widely believed that they cannot share those files, and they think it's not legal to do that. And what they really think is that it's a violation of copyright. And that's in fact not true, but as an indication of how common this is. Blackboard is the most common learning management system in their accessibility aspect is called Ally. Nicholas Matthias, the product owner of Ally, did a study of all the materials they've checked in since 2019. The two thirds of those educational materials that they checked in for accessibility were duplicates only one third of them were unique and that was out of 825.72 million assets. So, John basically wrote a grant, put together a team. That is a collaboration between academic libraries, repositories and technologists and the disability services offices at the participating universities. Sorry, this zoom is blocking my advancing my slides. It's a four year project funded by melon actually two grants we got initial grant, a two year grant and we are now in the middle of the first year of the second grant of the project. It's, as I said, a combination of libraries repositories, DSOs and university presses, and the big part of the, the work involved in frame is creating a repository where we can provide federated access to metadata and source files and other source files, files for a DSO to remediate, and then a place for them to put the files that have been remediated so somebody else can use those files. And then the DSOs have access to retrieve or deposit files and ensure that the recipients are qualified and that's really one really important aspect that you need to understand that the DSOs provide is they're the ones that are responsible for ensuring that a given student or faculty member or recipient of the quality of the mediator files is qualified to get them. The libraries and DSOs are at George Mason, Illinois, Northern Arizona, Ohio State, Texas A&M, Vanderbilt and Virginia. And the repositories are Benetech Bookshare, which is a repository of all remediate, all accessible content. HottieTrust, which is millions and millions of assets.  There's also a lot of content that's available between these three repositories. And then the fourth repository that we've created at Virginia to hold all the materials that did not originate in one of those three. Most DSOs obtain the files to remediate either from the publisher or the bookstore or a faculty member or a service like access to network, etc. Those files that they are able to interchange are put into Emma. And we're going to be adding ACE, which is the accessible content portal from the Ontario Council University Libraries and that will be our test of Marrakesh because of testing out the kind of differences in the exchange principles between the US and Canada. That's going to be interesting. So because of this misconception about copyright, the first thing we did was really an environmental scan that focused on addressing these legal issues for the DSOs. There have been a group of legal experts in January 2019 at ARL in Washington to an accession called the law and accessible text that resulted in a white paper reconciling civil rights and copyrights the law and accessible text so that very clearly documents that copyright does not prevent the sharing of these remediated files to qualified recipients. In that context, we also identified, not the not the legal activity but the frame activity in general, that there was no way identified two things that are really needed. There was no really good metadata model for remediated assets to describing how they have been remedied what are they and how they've been remediated. So we have created a metadata model and are implementing that. And then also clear need for education about accessibility and remediation in academic and library contexts. So for the metadata model, four different main aspects, a lot of unique identifiers are needed to make, manage all this content. And by the way this metadata model really has two uses one is discovery of assets across all four repositories and so that involves a kind of a massive unified search project that's been ongoing since the beginning. And metadata associated with these remediated files so because that what a what a DSO at one university is looking for is a file that has been remedied in a certain way that's how their student needs the file to be remediated and we need they need to be able to trust that the metadata can can tell them that. So, in addition to the bibliographic metadata and administrative metadata, we have a host of remediation metadata things like format file type features obviously if a book has tables or equations those often require a lot of work in remediation. So how how clean is the text on on the in the source file. Any comments that the previous remediator can make. And then of course EPUB accessibility metadata. And so at this point, still working on the unified search to refine that across the repositories and also refining the user interface for the deposit of the mediator resources. And also developing a more standardized batch upload process because you know one thing that happened in the first phase of the frame project is that all of these universities had a backlog of files in fact it was, it was somewhat amusing that many of them didn't want to admit that they actually kept these files because they had been under them, you know, misconception that they were not able to share them but they put so much work into them that they were not about to just trash that right so they had. The libraries had hundreds of files to contribute. But of course they all had their own way of keeping track of what what the files were and what had been done to them etc so fairly messy process we're trying to standardize that in phase two. And then integrating with two new partners repository partner ace and university Ohio State. NISO is planning to create a working group in 2022 to standardize the metadata model that we've come up with so that it's, it can become international, ultimately an NC standard. And also to create a membership organization so that this project is self sustaining. We don't expect to get more money from melon, but we do expect to add more universities. So, the membership model is how that will be enabled this this project to be self sustaining going forward. And then Steven is heading up the project for creating these educational models modules on information services for graduate professional curriculum. So at this point, I will turn it over to Steven. Thank you ever so much. Fantastic presentation. Thank you. My other colleagues for their great presentation so far I'm Steven Downey and I, I'm a professor of library and information science at the school information sciences at the University of Illinois at Urbana champagne. I'm sort of my contribution I'm coming, coming at it from library professional educator role, I'm also the associate dean for research so I find all of these unique problems, absolutely fascinating. So, what we're doing at Illinois and contribution to the project. If we go back to the list of people that we could. So, I just wanted to mention, it's teamwork. And what you'll see there in the dramatic persona is a wide range of skills that are coming together. You have me as sort of an academic educator. And we have professors from University of Wisconsin, Milwaukee, and she is an expert, a world renowned expert on creating accessible and teaching accessible information systems. And she's helping us lead our education program. We are working in conjunction with Kyle Rift guess who is the Illinois preservation librarian and has been working on the frame Emma systems metadata processing since the beginning of the project so there's practitioner knowledge there. His colleague JJ Pianke is the applied health sciences librarian. And that's the unit in which our disability service organization resides at University of Illinois it's called Dres disability resources and educational services so there's that lia liaison there. Professor Pianke is also an expert in teachers in the area of accessibility disability services. Jacob jet is a postdoc of mine, and he works with me at the Hardy Trust Research Center, his expertise his PhD is in metadata. And as we'll see in a minute, there is that tie in in the project where we need to learn more and teach more about the unique metadata issues that arise when dealing with these kinds of services. And then we have Angie Anderson, who's from Dres at Illinois and she has been historically part of this project from the beginning she has been doing remediations of texts for many, many years, and is also consulting on how to create the foundation that Dean Unsworth would like to create to sustain all these efforts. And she's assisted at the Dres at Illinois with Alice Cordain so what we're seeing here is a great team of different sets of skills and the reason we need all these skills. Next slide please.  We, with this professional for masters of library information science will be delivering it online so other folks from other schools can join without difficulty. And so to help train library information science professionals to to take on these kinds of roles in this new environment. But also we're going to fragment the materials and make it more modular so that we can take, we can grab, let's say the lesson on metadata and have it stand alone. As a possible resource, because we need to educate multiple people in this realm we, the people that work have their home bases in the library is one constituent but you also have people that have their home bases in the teaching units, or in the disability service offices, and they don't know about metadata it's not they're it's not in their wheelhouse. So we're trying to bridge uses education as a bridge between the different communities the different offices and stakeholders. And so that's why we're releasing materials online and as part of the project in our promise to our funders of the Melon Foundation, the materials will be released under an open license so other library information science education professionals can grab them use them libraries and DSOs can grab them use them to train staff to train graduate students as they come on board with the various projects. Next please. So, in general, we're looking to provide general background on disability issues in higher higher education settings so students what kinds of disabilities whether challenges what are the accommodations. are available or necessary. We need to explain the work of DSOs and organizations like Dres to the library side and explain the library side to the DSO stakeholders so again that bridging aspect and explain how to use the metadata. There's a unique kind of metadata being developed by Bill and Jacob and the team writ large. So learning about how to use it how to create it and how to make it take advantage of it is important for all stakeholders and sort of nitty gritty of document file formats and different automated techniques that are available for remediation. And also to explain the legal frameworks so that they're better informed within their organizations on what they can do this, this panel, for example, has helped highlight the legal, the legal support for our actions that needs to get propagated to the broader community. And of course, to introduce to all the stakeholders, new opportunities for research, what's what's next what can we do to make things better. Next please. And over the course of the last year is the team coming together under the primary intellectual leadership of Professor Jay. And these are the tentative sort of units in our proposed master's class syllabus so you can see the different aspects that I've been trying to articulate here represented as weekly lectures weekly modules for the class so we have design guidelines accessibility in retrieval systems which is specialty of Professor Jay. And understanding the general climate of of work with disabilities and how to do user studies and so on next slide please. Design tools, the accommodations challenges and designing an assessment of the systems and services that frame participants with undergo and of course, you know, what are the open questions, open challenges in services with people with disabilities. Next please. And so that sort of wraps up on the education front. Please keep an eye out we'll try and broadcast when the modules are up for sort of public consumption we are aiming to launch the class in fall 2022. So I suspect things will be more available in the summer of 2022. And I'm going to turn off my mic and my video and that Professor Unsworth take over. So, in academic year 2022 to 23, we anticipate opening Emma to membership by universities and colleges in the United States and Canada. If you're interested, please email us at Emma for accessibility that's the number four at Virginia.edu. We will ask for libraries to partner with disability service offices on their campus in this membership. But at the moment, I do not anticipate charging libraries for membership. We do anticipate charging the offices where disability services report which is normally the office of the provost and or the vice president for student affairs, or their equivalents. Those will be used to sustain and develop the Emma service to expand its coverage from print to other media like video and to continue developing the metadata schema for describing human and automated remediation that's been applied to make content accessible. And Bill I think the next slide is yours. Hi everybody I need to get back to my controls here. I'm not sure if you're still seeing my screen, but the last slide is the links to the resources. We're not seeing it. Nothing. So these are the findings from an initial environmental scan that begins the frame project. Here's the legal white paper from the legal analysis and the link to to join Emma to those that are interested. So, and then here are the, here's the contact information for the four of us. You want to email us. Happy to happy to talk and provide any insight and information. Thank you very much.


Compass Guiding Safe Migration Launched in 2021 with the government of the Netherlands, Compass is a global initiative that protects people on the move, combats human trafficking and smuggling, and supports dignified return while promoting sustainable reintegration. Compass started as a partnership with 12 countries. Algeria and Sudan joined the initiative soon after, leading to 14 countries committed to Compass goals. So, one year later, what have we achieved? More than 30,000 migrants were provided with protection, identification and direct support. 13,000 people were reached with safe migration information in communities with high mobility, and almost 800 stakeholders received capacity-building training on migrant protection, human trafficking, sustainable reintegration and migration management in general. Compass also engages with local partners to support migrants in need. We are visiting one of them today. Welcome to Thradzof Hope! Thradzof Hope is a social enterprise that supports marginalized women by offering them trainings on embroidery, sewing and other handicrafts, providing them with self-employment opportunities. The International Organization for Migration through the Compass initiative is collaborating this year with Thradzof Hope to expand the centre's reach by increasing the enrollment of more vulnerable migrant women to their ongoing handicrafts training, and provide them with awareness on parenting skills and nutrition, which can contribute to both their and their family's lives. I have been working here for three years in the Centre for Work. I have studied a lot of embroidery, sewing and other things. I love the Centre for Work. I work very hard. I am learning at the Centre for Work. I am learning new things, I am getting married and happy with the work under the guidance. This partnership will also cater to Thradzof Hope staff by providing them with information sessions on IOM services counter-trafficking, child protection and reporting mechanisms to ensure that they have the capacity to serve and protect the female migrant. The main goal of this partnership is to build the capacity of many vulnerable groups of migrant women and to ensure that they have a sustainable income for better livelihoods. We are one year in and the journey has just begun. We will continue to learn, collaborate and protect to guide safe migration better together. The COMPASS initiative is implemented by IOM and funded by the Netherlands. For more information, visit www.iom.int.com


future of the online coaching is moving away from the volume model. So what does the advice look like that's different today than maybe before capturing those leads? Yes. This is what I call exclusive marketing. I believe the last four years has been categorized as inclusive marketing, which was put a net out and anybody that's under the net, take them and sign them up.  You are there, right? And so, dude, I was sitting in a room with this big business group, Kevin Nations, OG online, right? And Kevin asked the question to a group.  And I was like, man, that's a tough question. And he was like, no, these like the answer is one.  He's like, it's one motherfucker. And I was like, oh, okay, I get it, right? Because we've all been in that room and there's that one motherfucker. There could be 100 people in the room that one motherfucker makes it a terrible room. And then you could be a 10 people and it's an amazing room. So like that one person brings it down. Well, it's the same as a coach.  I mean, I had it.


I got into 4-H when I was 13 and I think it would be good if more people did it. I'm sort of surrounded by agriculture too and I'm learning so much that way. My parents are involved. We get eggs and we get food from the garden and we get honey from the bees. And I find honeybees interesting because they're so important in food production and if we want to keep eating apples and blueberries and cherries and stuff we need honeybees to pollinate them, so that's why they're super important. I think 4-H helps people see where they can go and you get to learn so much. I think that's super great and it's really helped me because I'm not naturally good at public speaking but we do it so much every year that I think I've gotten a lot better at it and it's a lot easier for me. 4-H gives people a lot of opportunities and I think it helps people that way.