 Dwy'r ffordd i'w ychydig. Rydyn ni'n gwybod i'r ysgolwyd. Rydyn ni'n gweld i'r ddegid, fe'r rydyn ni'n gwybod i'r sefynt y ddefnyddio i deblog 13. Ion, i, i, i, i os ymwneud yn ddigwydd o'r ddebydd ar y taimgwn i'u dyfodol i'r cyffredinol. Ac mae'n ddebydd o'ch dyfodol i'r dyfodol i'r dyfodol i'r dyfodol. Okay, so y Demian Archive is, amongst other things, a version control system. You can clone things by doing App Get Source, or check out if you're a bit retro, if you'd like to think of it like that way, and when you upload, that's like doing a commit or a push or maybe a together. But the archive is actually quite a bad vision control system. It doesn't have sensible branching. It's history browsing is terrible. It's interaction with other ECSs. There's a lot of tools that have been written, but it's still pretty bad. And many of us want to be using Git. Now, I know some people don't want to be using Git. That's fine. You can carry on doing whatever it was you were doing before, and hopefully you won't notice too much. So for the rest of you, I'm just going to from now on assume that you like Git, or at least can bear to live with it because, well, yeah, let's not go there, shall we? So, what to do about this problem? Well, we could replace the archive. We could replace the archive with a Git server or something like that, but the archive is lots of other things besides being an upholdingly bad ECS, and replacing all of those other things, well, that would get quite complicated. And of course, a lot of our co-developers have been using the archive for a long time, and like many people, they fear and hate change. I fear and hate change, too, when it's not the change that I'm hoping for. So, you know, we should deal with this the way that we're used to dealing with these kind of problems and write some software. So, what we really need is a better gateway between the archive and Git, and that's what the Git is. So, the Git is a tool which lets you treat the archive a bit as if it were a Git server, and it provides the same uniform operation for all packages in the archive, regardless of the maintainer's workflow, regardless of the source control arrangements used by that team. You can clone absolutely any package, work on it, build it, test it, and upload it. You don't need to know the maintainer's workflow, it doesn't matter whether the maintainer is already using Digit, or using some other set of Git tools, or using Quilt, or CVS, or if they're keeping their Debian patches in SCCS, or God knows what. You do all the source code management directly in Git, and you don't ever need to interact with the archive directly. You just use these Digit commands here. So, now, I have a demo, and this demo gives me instructions, which is good. Let me just not quite see what I'm typing. Is that big enough? This is huge. I can't make it any bigger. Maybe I should be using Nome Terminal or something. I'm not sure I have that installed. Let's not do that now. I'm just uploading this here, and, right, there we go. What am I supposed to do? That was not what I meant. Oh, right. Yes, I'm supposed to edit it. Time to complete that. So, there we go. I've edited the change log. We'll commit it. Very good. Oh, I need to build it. Yes, of course. This will take a little while, so I'll just leave that running. Digit is particularly useful for NMUers, because you can prepare an RC bug fix, or a CVG fix, or whatever you like, with full support from Git, and you don't need to know anything about the package's usual VCS arrangements. If the package's clean target is broken, you don't care about that, because you could use Git clean. You can clearly see all the usual things. You can cherry pick changes directly from the upstream tree, all the usual things that you would hope you'd be able to do. Digit also has good potential for downstreams, so that is derivatives, users who want to modify a package. Having used Digit clone or fetch, you can merge whatever has been made in the deviant archive into your downstream branch, and you'll just get the right output. Unfortunately, there are some issues with this for non-DDs at the moment, which I'm going to discuss later. It's only good. At this point, I need to do a top secret thing with my PGP key. Well, I said it's top secret. I'm not explaining why. It has to think a bit, because it needs to check that all the ducts are lined up in a row. It needs to check that we're actually doing what we think of as fast forward. That is that the version we're uploading actually contains all the changes that are in the archive's Git repository. Of course, the archive doesn't have a Git repository, but we'll get on to how that works. There we go. Nice and simple. I didn't have to do anything that wasn't Git. I did have to do an s-build. We have some ideas on how to do source package less uploads. Of course, they won't really be source package less. There'll be ducts paddling very quickly in the background to make your source package, but in principle, I think this can be done without you actually having to notice that there's a source package. Right. That was the demo. Now I need to just undo that. Very good. Okay. As a maintainer, you can choose to use Digit if you like, and you can choose to use the Git history that you provide that Digit looks at as your primary Git history, or you can not do so. If you do so, then you can use Digit to upload your package in the usual way. If you have some other different Git history, then you may or may not be able to use Digit to work with it. Digit's requirements are that your Git history is a patches applied fast-forwarding Git history, and that the tree that you get out of dbx is identical to the tree in your Git repository. In particular, you can use Digit if you have the complete upstream history in your Git history. I'm going to go on to principles of operation now. Okay, this is quite small, isn't it? Well, we'll just have to live with that, I'm afraid. Get the slides up on your laptop if they're linked to from the little page. So yes, obviously you want to know how all this works. So I'm going to run through the principles operation. The key thing is the data model. The DSC, you've got an example there of a DSC from the Digit package itself, and it has a field in it Digit, and that refers to a Git hash, and that hash is the commit that was uploaded, or pushed if you'd like to talk about it like that. And as I say, that specifies a commit whose tree, whose Git tree is identical to the results of unpacking the DSC. So the DSC and the Git tree are just different representations of the same data. But the actual Git history isn't stored on the archive. There are various problems with that. I don't need to go into the history there. There are some real problems with storing the Git history in the archive. The archive isn't really set up to be a good Git server. So instead, it's obtained via the Git protocol from a special Digit Git server that contains all the Digit Git histories. Currently this is on and off, but there are a number of reasons why that's not good and it's going to move. I've been promised a VM of my own. Yes. So the other constraint is that the successive uploads in a particular suite have to have a fast forward in Git history compared to each other. So that is every upload must have merged into it somehow the Git version of the previous upload. So if the previous upload was done with Digit, then that has to be a successive, the Digit commit mentioned there. Otherwise it has to be the merge of the sort of gateway Git history that I'm going to mention in a moment. Right. Yes. I'll go on to that in a moment. But also I need to expand a bit on the need for the Git commit to be identical to the source package. So Digit is a way, amongst other things, of looking at source packages and the history using Git. And that means it, as we obviously the same as the package tree, files like configure, which turns out to be a contentious example, need to either be in the Git history and the source package or they must be in neither because the source package and the Digit Git history are the same. Or to put it another way, what you think of as the source code shouldn't depend on whether you're representing that source code as a Debian source package or as a Git history. Now people have different views about whether configure should be in Tables or whether it should be in Git repositories. Or that Digit requires, if you are using it, is that either configure is in neither or it's in both. So if you don't like configure in Git, then you have to have it not in your source package and presumably your source package has some other arrangements for building things. Just a very quick question. You said that this fast forwarding requirement exists. Yes. You gave the technical explanation, but what are the consequences for the maintainer of a package who uses Digit, for the maintainer of a package who doesn't use Digit and for the enemy user? Right. So for anybody who doesn't use Digit, they don't notice that anybody else is using Digit apart from there are some, you know, automatically generated patch file names and things like that. But in general, people who don't use Digit don't need to be aware that it exists. If you are a Digit user, then so if you're an NM user, this requirement will pretty much be automatically satisfied because you will Digit clone the package and that will produce you the Git history that you'll be working on. You will make your commits on top of that and naturally the result will be fast forward. If you're the maintainer, particularly if you're starting to use Digit for the first time, you will find that you have to merge, you have to explicitly merge in Digit's idea of the history into whatever your current idea of the history is. That merge doesn't have to be a, it doesn't have to change your actual tree. You can do git merge dash s hours to say, I declare that this thing is somehow an ancestor, a descendant of the other and then Digit will be happy that what you're doing is intentionally superseding. Does that answer the question? Okay, so I mentioned configure. So there's what to do about non-Digit uploads, like most of the archive at the moment. So here we have an example. That's really quite blurring. I should have used a bigger font for this, but then it wouldn't have fitted. Where was I? Yes. So non-Digit uploads don't have a commit hash in the DSE. But Digit clone needs to produce a suitable Git commit. So what it does is it invents currently in a deterministic way a commit that corresponds to the package it got from the archive. So when you say Digit clone or Digit effect, you always get the authoritative saying actually from the archive. It's just that sometimes you will get some real Git history if somebody may use Digit for the last push. And otherwise you will get a kind of synthetic history that looks a bit like this you see on the bottom of the slide here. This is just an example package. Here you see this is a package where somebody used Digit to upload 180-1. And then later, for whatever reason, the next upload was not done with Digit. And if you do Digit fetch, Digit has synthesized these two commits, one of which contains the actual code and the other which is this merge which just says we found this package like this in this suite. If you have a longer history, that will appear somewhere in there. OK. So Digit's biggest problem at the moment is with Quilt 3.0 packages. So there's a few difficulties there. At the moment Digit doesn't do anything very clever with them. There is a requirement that you must be able to deep resource-x the .dsc that it generates and get the same thing as in the Git tree. And this means that the Git tree must be in a sort of deep resource committed state. So Digit, when you push, will run deep resource commit for you and generate a patch containing the changes that you made with Git. It's not able at the moment to split that up into multiple Quilt patches or or anything really very sophisticated. You just get an automatically generated single automatically generated patch. And likewise, when you Digit clone a Quilt package, you don't get a Git history that looks like the Quilt patch stack. You just get a single, essentially a single commit that was generated by importing the actual tree that was produced. So together these things mean that when you work on a Quilt package in Digit, you don't interact with the Quilt patch stack at all. To people who are using the archive other than via Digit, it looks like you are a completely naive maintainer who didn't know anything about Quilt. Now, you know, notionally our processes support this. This is supposed to be a permitted thing to do if you're doing an NMU, but in practice I have had some grumbling from people about things like this. The maintainer of this particular package, they said, well, you know, yes, okay, thank you very much for the change, but it would have been much better if you produced this in a form that was more easily, didn't require any further massaging to fit into their own existing Quilt stack. I do intend to improve this perhaps by having Digit use some kind of tool as a bi-directional gateway between Quilt stacks in source packages and Git brushes, but exactly how to do this involves some very complicated design decisions which are nowhere near having worked out. Every time I have a conversation with somebody about this, it seems that they have a different workflow and a different idea of what the Git history should contain, and a different idea of what the various trees should contain, and most of these ideas are incompatible. This is obviously no good because the whole point of Digit is that you should be able to use Digit without understanding what the maintainer's chosen patch strategy workflow is. You should just be able to commit. At the very least, you should be able to just commit changes on the top without understanding their branch structure or in their native Git repository or whatever. I think this can be improved. Exactly which of the current Git-ish patch management workflows can be supported or at least can be made compatible with Digit is a bit of an open question, and I'm happy to talk to people about that really afterwards is probably best. Particularly if you have some strong opinions about it. So probably the biggest problem with Digit right now is this. It's really at the moment only useful for DDs. I'm finding this particularly galling for a tool which is most, you know, which is especially useful for users and downstreams, mentees, people like that to have it accessible only to DDs who are much less in need of this kind of support is quite unfortunate. So there are two really big obstacles to widening this access. One is related to the archive and one is related to the Git server. So Digit needs to query the archive to find the DSC, the current version of the DSC that's in the suite. We've got a question from Colin. I mentioned this to somebody earlier and they suggested using UDD for this, UDD.devint.org. Is that something you looked at? Yes. Okay. It doesn't have quite the right data quite quickly enough. Okay. So not off hand. This was a long time ago. It was like six months ago. So at the moment, there's not really an official interface for providing this. The UDD doesn't provide, I think, all of the fields that I get out of that select. I also have experienced some weird skew problems. Does UDD access the project B directly? He says it gets synced on a mirror push. Well, that's too slow, sadly, because if you need the actual access to project B to minimise the period of time during which you might accidentally upload something that to Digit would look like a fast forward but was actually squashing a previous upload. So what you might actually want to do is fix that a little bit to expose this information via metadata FTP master Debianog. Right, indeed. So I'm coming on to that. So at the moment, you can see what I do here. Maybe at least the people in the front can see. I'm doing some hideous thing where we ask you to mirror FTP master and run a piece of sequel. But FTP master have promised me a proper, supported, secure data query service that will allow me to, that will answer these kind of questions. I understand this would also be useful for some other users of the FTP master database mirror. I think maybe contributors Debian net could, Debian all could usefully use such a service as well. So when that's fixed, obviously I will change Digit and it will access this service. And then where you see in the table there needs project B data service, those problems will be fixed. And that will allow at least DMs to fetch, but not yet to push. The other problem is that Digit is using Allioff as its Git server. That's project B is the database that DAC uses. That is the main Debian archive, has a database that records what packages are where and which suites they're in and what versions they are and what files they're made up out of. And that's all scored in this database called project B. Project Betsy, I'm told, for reasons lost in the midst of time, says Colin. Yes, well, who knows. So right, I'm on to the Git server. So yeah, at the moment we're doing, we've got any area in Collabaint where these Git repositories live. This is not ideal for a number of reasons. Allioff does lots and lots of other very exciting things and is much less secure than it needs to be. Really, we want a Git server that's about to secure as the archive and that's certainly not Allioff. So DSA promised me a VM, which we'll move everything to. Yes, we've got a question here. DSA have approached me in the chat asking if there's a way to require DMs to have a user ID so they can enter them in LDAP and allow people with DM to log in into that machine. I think it's doable and I'm working on implementing this although I cannot talk about, I cannot guarantee a timeline for it. Excellent, that's very helpful. Right, so what we're talking there is, so when we move to this new Git server, there will be, let me explain and then I'll take the question. So I already have code that will receive a Git push from a server end and rather than doing the access control by username, it will do the access control by Git signed tags. This is a bit complicated because Git verify tag doesn't verify all of the tag but I've managed to work around all that and I have an implementation pretty much ready to go. The other thing that I want to be able to do is to allow you to push to arbitrary, more or less arbitrary branches in the DGIT server provided you have the relevant kind of access and for that we need all DMs to have accounts in LDAP. So this work for getting DMs LDAP accounts is a necessary component for getting DMs full access to DGIT. Moving DGIT to its own Git server will, that and the FTP master data servers will provide anonymous access but obviously only anonymous read-only access. Right, I'm just going to go on to my next slide now which has got the references on it because this is more or less what I prepared to say and maybe we should go right on to the questions since I see Daira quite a few. Yeah, you were obviously first. Yeah, so it seems to me that the contents of the Git server should be able to be verified by anyone who downloads them. So the security that that Git tag verifying thing that you mentioned seems important but the final place that the data goes after the tag is verified doesn't seem that important. Do you sort of see what I mean? I do see what you mean but I think you're wrong. So this is what DGIT does. If you run DGIT it verifies the signature on the DSC. I don't think this is the correct approach because the DSC doesn't tell you for example which suite the package is in which is important information. Maybe it was in experimental and it's really important to know whether this thing that you're getting was in experimental or stable proposed updates. Also it can fail the other way which is that if you're downloading some package and the maintainer who uploaded that has changed their key since or they've become emeritus or some other thing has happened then the verification will fail when in fact the package is fine. So I want this to have essentially the same security properties as app Git does which means that it needs to rely on the archive's view of the world not individual verification of the original source code. That's not to say that those sign tags and things aren't there if you want to do some kind of audit or monitoring or something but they're not the primary security mechanism. That makes sense. There is an alternative which is that you could have the archive generate commit IDs that people should trust and that just shows up synchronised out to the fgp mirrors and so on and that's an artifact you get via app get something. That's basically what's happening right so if we go back this DSC file that comes from the archive. The SHA256 sum of that DSC file is in the project B. When we have a new FTP master data service and indeed at the moment with the SSH SQL rune you SSH to the FTP master database you get the hash of that file you download the file comes from some mirror and you know the mirror might produce a corrupted version but DGit will detect that and so you do have a chain of trust back to the FTP master database. Right in which case it seems like you don't need to trust the git. You're talking over the person with the microphone so I can't hear him and nobody can hear you. It seems like if you have that you don't necessarily need to trust the git archive then but I'll yield to other questions. Joey is saying that this is in the sources file and therefore you don't have to use apt but of course if you just want to DGit clone a particular package you say DGit clone blastsid and you're on stable the last thing you want is for that to involve downloading SID sources file. Can you go back to the table you had in the last two? Sure. One last slide. I don't believe Anonymous is not desirable. Anonymous push. It should be something like git format patch. That would be awesome like you know DGit format patch sends the thing to the BTS. Yes that is desirable and the the command you're looking for is called git format patch. You do git format patch your maintainer sponsor whoever it is will do git AM and DGit push and it will all do the right thing. So the problem that we have with the 3.0 git Debian format was that it would contain potentially contain commits in the middle of history that contain things that we didn't want to distribute or that were under various licenses we didn't like which was the and that all that stuff would have to be reviewed. This is pretty close to using git as the packaging format except that we're storing it into a different archive up until the point when only DDs and DMs had access to the actual git archive. I understood how you were getting around that problem. Now that we're talking about opening this up for anonymous access I don't understand why we're not back to that same problem where the where the where Debian is distributing files which are potentially under licenses that we can't that don't let us actually distribute them. Right so the the the short answer to that is that we are already distributing all of that kind of stuff. We're doing so from Alioth and this is no worse than Alioth. In fact it's just like Alioth only it's more secure. The problem with git history in the archive is a there's a there's a contested conversation about that and it turns out that in order to do this I don't need to change anybody's mind about the desirability of you know having the full git history available to people from a Debian machine. We've already crossed that bridge with Alioth so I don't think we're making this any worse. Now there is of course a potential practical difficulty that if some packages git history turned out to have unredistributable stuff in it or illegal stuff or what have you and that actually you we noticed or somebody sent us a lawyer letter or something and our response to that would be to use administrative access to the git server to wipe out the history and probably have some kind of commit object blacklist or something to stop it from coming back. This has not yet happened to Alioth and given the amount of stuff from just about anywhere that appears on Alioth I think you know and I've not heard of similar problems being a big difficulty for other projects so I think in practice we can afford to cross that bridge when we come to it. We do have a plan for when that happens but we haven't written the tooling to do it in a really nice way. One other really quick question the you said that the when you push to digit it has to be a fast forward from the previous upload to the archive what happens when you want to branch the package for stable updates or backports is another example because those would seem to you would seem to then need multiple branches and digit and they wouldn't necessarily be fast forwards of. So each each suite um you know what a suite is a suite is something like squeeze but each suite is on branch already each each suite is its own branch and those branches are in themselves fast forwarding okay more questions I've got a question uh I am sorry uh so I'm not a devian developer but that's not interesting for the purpose of my question which is I'd like to use digit in a non-debian context are there so I've got source packages that I'm importing from devian and patching locally and right now I'm checking in dsc's to subversion which is miserable uh and I find digit compelling and I want to know if you think it is easy for me to set up an instance of digit pointed at a local git repository uh to import dsc's from random places right so if what you're trying to do so there's sort of like two sides to your question there's the interaction that you're having with devian and there's the interaction that you're having with your local source code management arrangements um as regards your interactions with devian digit will solve that problem for you but you're in that anonymous fetch clone access box there so that doesn't work for you right now and I'm very sorry um as regards your local source code management practices um if you have set up something that looks like the devian archive already and you're uploading things to it with depot and stuff like that then um in order to interact with that using digit you will need to also set up a git server and you will need to teach digit how to query your project's packages database now there's a sort of pluggable modules architecture in digit for this um one of the reasons there's a pluggable wall of modules architecture is that I kind of anticipated that you know this would be necessary and derivatives would want to use it this way um and the other is that I have flailed around terribly trying to get some kind of working access to the ftp master database the current implementation is the third set of such code um after the first two attempts were found to produce wrong answers um so I do know that that switchable stuff works it's you know obviously the configuration and stuff that gets a bit intricate but in principle um the design does not exclude you using digit to fetch from or upload to another distro providing that other distro has some suitable infrastructure that you can speak a practical to regarding the anonymous clone business uh is it possible for me to tell digit to generate the history against an archive against just the debian apt archive or some other apt archive and then check in that history and to a local gift repository and having done so if it's to digit sports this can I then later reintegrate with debian once you guys open up access right at the moment you can't use digit to talk to the debian archive unless you're a debian developer so the very first step that you described there doesn't work even if i'm okay with it being out of sync so even if you're okay with me you have no pluggable architect you have no implementation of this plug all back end that just fetches things from the mirrors uh no i don't um you could probably switch over to the there's one that uses our madison which is probably mostly okay yeah i mean i switched away from it because it broke a lot um you could probably switch back to that and then you get mostly right answers i guess that's i mean right now we're writing out get sour so that's fine there's another problem which is that uh digit needs to test whether the gift repository already exists on alial and that can't be done with the standard gift server because the standard gift server thinks that you want to hide the existence or non-existence of gift repositories and gives the same error message for this repository doesn't exist and you lack permissions uh but if you have an alioff account you can get around that so an alioff account is pretty easy to come by sure um so i guess hurry before i move it off alioff because when i've moved it off alioff you have to update your digit to a new version that speaks some other protocol to my gift server to find this piece of information all right so that's good thanks any more questions joey here you keep your hand up for the mic run thank you um so i guess my question is digits around now for about a year i think about five or six people have used it to upload to the archive and they've uploaded maybe 50 packages or something like that right um and it's maybe a question of the audience but also to you um why haven't we had more users yet and i have a follow-up but yeah right so um so i think this problem is so you have a lot of dds who are you who could be the users right so um another problem is that if you are currently using 3.0 quilt and you want to continue exporting quilt patches to people who are not using git no they don't have to be using digit because you can push your gift right somewhere else so that people who aren't using digit can still you know clone your staff and send you patches and what have you uh but if you want to continue exporting your patches as quilt then you've got a bit of a battle on your hands you want to kind of like warring git workflow tools and it it doesn't work very well um and over the last few years since quilt 3.0 came in a lot of people have decided they really like it um and since digit doesn't work with it very well i think that's the that's probably one of the biggest hurdles if your package is currently in if your package is currently native or if it's in 1.0 um then these problems are completely irrelevant to you and i can and if you like using git i can see no reason why you wouldn't use digit so i guess as a follow-up to that i should say that two other you listed two ways that it's useful uh two other ways that i've found it useful is one i sometimes just want to get repository with a package and i don't really care about cooperating with the debian developer because i'm just doing my own development and then i'll probably send them a patch or something and i can just digit clone anything that works um of course i'd often don't push it when that's the case and secondly um sometimes i'm working with a package and they're in some insane version control system setup that i don't feel like dealing with even though i know what it is and say i'm back porting it to weezy or something and i would like to you know i don't feel like trying to figure out how to set up a branch in darks for a haskell package that i'm back porting to weezy so i just digit it make my mods and push and you know that works for me too um but i am kind of curious what the you know why everybody else in the room hasn't tried it maybe they have i'd be curious to know these things right i can't really answer that question um i don't use digit anymore right why would you use digit when you've got digit you can use digit it does just like the digit does only you get a git tree and then you can work on it in git and um we all spend much more time reading packages than we do writing them so if you look at the archive and look at the you know the proportion of source packages that have digit fields that corresponds to people who've done uploads of digit and you all the people who have just gone and looked at some package and used it to prepare a patch are invisible um maybe part of the answer is that we all spend those of us who like good quality version control systems spend more time working on our own packages in them rather than other people's packages that aren't yet set up with them or perhaps uh there is less need to work on uh native packages and there is to work on three zero quilts type packages maybe um i can imagine theories like that skewing things a bit uh so i think see you is next i can just tell you really quick i don't use it because i didn't even know it was usable so it's been usable for quite a while well some of us are old and tired of moving from one vcs system to the other and so have limited amounts of time to invest in them um half facetious is a comment but in you know the reality is i did follow with one eye the the digit discussions um last debconf and i'm happy to see the direction you've taken with it and i'm looking forward to using it but in terms of things that i need to see before i'm willing to adopt it um you know one is the the three oh quilt most of the packages that i have today because one dot oh only works if you've got tar dot gz um and i've got a lot of packages which are not native three oh quilt is the format and so if it's going to interact badly with that i mean even if you're saying you would not recommend it for somebody who maintains their packages and get because the the output for three oh quilt is so bad even if i'm not looking at it myself then and i'm not sure if that is what you're saying but right so if you're maintaining your packages in git at the moment then either you are using some kind of one of the existing git patch manager plumbing tool things of which there are people keep mentioning you ones to me at least for i think there's about i think i've been told about of about six but i couldn't enumerate them um either you're using one of those to somehow generate a thing that looks like a quilt 3.0 package out of your git history or manipulate it with git or your quilt package is well you know you might be using 3.0 single debian patch or something like that um where the thing that you get in the dsc in the source package is not a rich history at all and all of the history management is done in git and if you're in that latter camp um and your git tree is sort of vaguely sane then digit is already perfectly good for you if you are using one of these git patch manager things to gateway between 3.0 quilt and git then this is the thing that's that's that's biggest on my radar in terms of of making that work well um and i'm i'm actually hoping that i'll get like have useful conversations with people about what the data format should be because i think the data model is the the key thing that i don't really understand so then the other thing um as a as a both as a maintainer and as an nmu or i care about having a i care about having the rich history that comes with having a package in a vcs as opposed to just having um upload level granularity um and i understand that where things are today is that if you have that rich history and you are using it for your own package that you can merge things in um but then the history looks like you have this this one point where you've merged everything together and there's no stitching together together of the previous history on account of the fact that digit requires the the history to be fast forward from what it's already done so because digit has already imported um to to merge in the rich history that's a one-time merge and so you can't really use the digit tags to traverse in any meaningful way the history of past commits to try to look at where in the history something changed in a way that's relevant from like the package versions no i don't understand your question um so if you have a package that you have that you used to maintain some other way and you now maintain it in digit then the there will be one little stub thing in the in your ongoing history which was the part where you told digit that your history is actually better than its history and to just ignore the fact that the you know just to say make this a fast forward from that and your ongoing history will contain all of your actual history which which means that so if i suppose i have all of your tags and all of your everything can be just the same as it was before but suppose i have a package which isn't in git today uh and that i isn't in git today then um if you want to if you want to have a rich git history that shows you the history of the package and you've got the package in some other vcs then uh what you should do is you should convert it using some repo conversion tool from sccs to git and then and then you can do git merge as s hours the digit branch and now you can push that makes sense but sounds like a lot of work and i haven't gotten around to doing it for all the packages i care about right that's a perfectly good answer um i think the back there and then here and then lucas hi uh for a lot of to sort of respond to the question about why i'm not using digit yet partly is i didn't realize how very usable it is yet partly is because i spent a lot of time reviewing packages by non developers and non dms who are mentees on mentors dot demi dot net where they throw dscs to the wind and uh i guess my question is can i digit clone a non archive dsc is that an operation that makes sense um you can't at the moment um as currently constituted digit has baked into its configuration the location of the git server to be used but in principle that information could be in the dsc uh the reason i didn't put that information in the dsc to start with is because you're not really guaranteed that that so a dsc can live beyond the you know when you mention a server name that server name you know it might be down it might be renamed who knows what um that would be not a an implausible design change it's a thing i've considered um even using the vcs git url might you know might work some of the time um your person publishing the dsc will have to publish both the dsc and the git branch and they will have to know the url at which the git branch is available um so that they can tell digit so that digit could put it in the dsc and so that your version of digit can find it mike and it's not your i was going to say what jerry said which is that digit could just uh could disable half of its glorious functionality which is kind of sad and just you know import the silly thing uh the other is yes it makes more sense for mentors.divinotnet for example to publish some git data or something that's totally within the realm of possibility although it's slightly harder to require that for every dsc that people who have to upload to other places like their personal home public htmls uh that they want review on right so um the the reason we've got these two um two storage locations that need to be kind of both accessed and synchronised is because of the other things that the archive is trying to do and the restrictions on what can and can't go in the archive if what you're trying to do is actually just share source packages with somebody then probably you will be better off just sharing the git branch that right so if you're the person sending you the code is already using git then 10 minutes um then having them package that source code up into a dsc and then you unpack it again is is not necessarily the best way of of transporting that source code about git can do this kind of thing somewhat better um but we had some more questions um you weren't next did you you weren't next did you think about us you were not the next question yeah it was actually a follow-up to Steve's question earlier about rebuilding the history have you looked into importing from snapshot the biannogs that you could get the story since 2005 um i haven't looked at that myself i know there's a tool already that can do this um that would be great um one of the reasons i haven't done it is because i want digit clone of some package to actually complete in a reasonable time um we're out of time that was a very short 10 minutes oh i see right well we're to stop thank you very much