 Can you introduce Scott James Remnant talking about package management and version control? I was trying very hard not to say package control and version management. Okay, so this is going to be basically a rehash of a talk, okay, by the Buntu down under. It's not related to the package. This is the stuff I do for Kaniak or every day of the week when I'm not hacking on Debian stuff. But it's hopefully potentially interesting for Debian, and Debian may want to actually play with it and use it. The talk is actually quite short. It's not actually supposed to fill the 45 minutes we've got here because it was only done for a 20 minute talk. So basically if anyone has any questions or anyone wants to discuss them, I'm going to run this a bit more of a bof than a talk to kind of fill out the time a little bit. So feel free just to stick your hand up and shout out a question or comment or anything like that as we go. So the basic introduction to this talk is a talk that Kononiko has been working on called the hypothetical change set talk, which proves just how bad I am at coming up with names or things as anyone who's experienced any of my software will know. The idea of the HCT was to make handling source packages a lot easier. We often have in Debian source packages which we have an upstream for and stuff like that. It can be a bit of a pain to kind of manage them sometimes, especially when you want to actually take into account things like updates between the upstream and the new packages and the things like that. The idea of the HCT was to do all this using revision control systems. Revision control systems are pretty good at doing what they do. They're pretty good at losing your data. They're pretty good at giving you nonsensical command line UIs, but they're also, fortunately, especially the more modern ones, pretty good at helping you do merges and pulling new changes and do diffs across things and things like that. Hopefully, this is going to be kind of an interesting talk about what we think is the way of doing it. What is the HCT? It's not too bad. It does actually fit on the sliders. Pretty impressive. Basically, the HCT is about source package management. Finally, packages you build and the handling through being by dPackage. If you wanted to see the dPackage2 talk that was on Friday morning, you should have gone up earlier. I did, just. This is about source package management. What we do is we use source package management. We use bizarre branches. Does anyone here not know what the bizarre is? Everyone's come across it. It's economicals fork of TLA, basically. We kind of got to the situation where we wanted to use TLA for things and there was too much pain involved with it. We basically forked it and created a separate branch which we call bizarre which focuses on giving it a friendly user interface. A lot of the ideas, we stole a lot of the UI from Subversion and it's being developed by Robert Collins, who was one of the upstream arch developers before he joined Economical. It's slowly progressing. There's another project called Bizarre Engine which is a project to create a completely new virtual control system which has similarities possibly to bizarre, but it's actually not based on arch. That's what we think is a good future for original control. We fund these projects simply because we think it's the right way forward and it's unrelated to them except for, as I'm going to talk about here, otherwise we just use the one-two-slide for a bit. The basic way it works is that tar files, the upstream tar file, the p-threads tar file in GNPC, whatever crap you've got in your source package, are managed as branches. There are trees in particular senses and so are the patches you make to them. We go one step further, but the patches you have to a particular tar file are made up as branches off the tar files. So if we take the exuplicant thing, which I was just playing with while we were waiting, the exuplicant original tar file would have a branch which contained all of the history of the original tar file and then off that you'd have the exuplicant final names dpatch branch which contains just the changes as change sets from the exuplicant tar file for the sort of the asset to make that actual patch. And it's basically built up on these simple things. What the magic of the HTT does is it can help you manage these just by referring to the patch file names. You say you want to work on a particular patch file name and it will just do so. And it also lets you build it into an actual Debian source package that currently exists today with creating patch files for you and so on. So the advantage is for a single developer of doing this doing this kind of thing in revision control. Basically, there's sort of work for that. To change a patch, let's say you want to change the exuplicant final names patch, you just get it, edit the files. So you just literally, by getting the patch, you get a working copy which contains the original source with the patch applied. You edit the files in it. You add and remove the files just using version control commands as well as whatever you move. They actually provide some versions of these things. And then you commit the changes. And that's all you have to actually do to trade the patch. There's no kind of worrying about different patch and things like this. The way it kind of works is built into a revision control system. Now I'm going to try and do a demo here, but given this was actually just set up just now, it may not actually work. So let's have it go, shall we? What we should... Don't do that. Can you hear me now? No? Ah! That was a lot. Right, we've got a channel. So you can... So the ACT command kind of based on the... the source command get and work with source packages a little bit like act get source and you give it a silly URL. This was picked by Phil this morning, well just a couple of minutes ago. Ignore... The local host bit is just because I'm trying to do a demo here and my network access doesn't seem to accept the fact that there is more to life than HTTP. And normally you just say source, source package. And that just lets you work on a source package. And we can go into the subsequent directory. We can see what's in the source package. So this source package has the original source, this is a hsubcon101 step in directory. It's got a patch of the tarball and it's got another patch of the tarball. Oh, scroll off the top. And it has a tarball, the original tardo z. So if we want to do edit this hsubconparnoves patch this is probably where it goes all wrong. You can edit it, it goes to the hsubconparnoves patch and there it is with the original source applied. And we can do that. And you can use version control commands and stuff to see that the author's file has been modified and things like that. And if you want to prove that it actually works. I fully believe in shortening things as far as possible so it lets you kind of cheat a lot. So just slow it a little. So this is a little bit hacky, but you wouldn't have to do it. AuricTarGZ is a branch name there? AuricTarGZ is part of the file name of the tarball. And I'm just cheating for the purposes of downloading or anything else. So we should then be able to show you the differences of hsubconparnoves.org And as you can see, the differences from the origin is patch branch now. We've added some random jobs to the author's file and there's some changes to the documentation and whatever. The file name changed there. So you can see that now. And you do this in revision control. And for those people who know about sort of as can actually look at the branches and look at hsubconparnoves. And you've got AuricTarGZ, there's a packaging which is the Deviant Directory. It's the hsubconparnoves branch which... hsubconparnoves.org which is a tag of the AuricTarGZ with the changes from the 1.01 release merged in and if we're committed then we can do that and actually commit to our own thing. So the basic idea is you can do all this using revision control. To edit a patch is just, you know, literally check out the branch of the patch, change the check, make the changes you want to it and commit it. Which for us makes the workflow a little easier. You don't have to worry about this. A lot of this is based on ideas like things like what we're going to do today and it seems like CDBS stuff and things but the idea is to do it in a revision control system rather than just trying to fake one on disk. There's advantages for a team as well. Version control makes collaboration really easy. As anyone who's kind of used subversion or CVS or stuff like that will know, if you've got one single repository for your package you can just collaborate on them. You don't have to worry about swapping patches. You don't have to worry about mid-air collisions. We tell it too much. By actually representing the patches as branches rather than a patch file being used as a subversion, if two people edit the same patch branch but edit different files, that's fine. If you've done like the current people do and you just submit the patch into subversion, then if two people edit the patch in different ways, you're going to get a conflict both either way. By representing it as an actual branch, you can, you know, it's just as easy as working on the branch with another person. You can work on the different patches without conflict quite easily. I mean, you could do that today just by bringing patches to version, but here you can obviously work on different branches and different logical spaces with a distributed revision control system like Versailles. You can sort of work on it on your own machine and sort of away from, you know, when you're in a plane or something like that quite easily and still commit and stuff. And obviously you can work on the same patch using updates and merges. So, you know, there's advantages for a developer who makes their workflow easiest. You know, we've got tools today to kind of help them do that without using a revision control system. This does it with a revision control system. Obviously there's, I think that was probably the one. I know there was one more. So obviously there is particular refunds which is as well. I mean, if you're doing it without a revision control system, hands up here who's been playing around with this source package for two weeks and realised everything they've done is completely wrong. We had to roll back to the version we had two weeks ago. Anyone done that? Most of us. If you're using a revision control system, you just back out your changes with the file-based system. You have to hope you kept them around, especially if the two weeks ago wasn't the last upload. So there's various advantages to doing things like this in a revision control system as opposed to just, you know, on-the-fly and baking one. The way HTT works, primarily it's written in Python. It's going to open source talk, so if anyone's going to pack it, to get all of its data about source packages, where they are, what they're called, what's in them and stuff like that, it uses something that I've been working on, a canonical I've been working on, called Launchpad, which is a giant database of information about the open source world. And the kind of data in there is, you know, like kind of a supercross between fresh meat and source forage and bugzilla, every bugzilla in the world and language translation system. It gets a bit hairy, but in there we actually do have the information about source packages, so that's where we get our information from, so that's this next slide, which disappears off the side. So the basic idea is, if you want to publish your package without publishing to a distro, you can just push it onto, you get, like, with your account, you'd get a personal space and a personal kind of app repository and things like that, and it will automatically be built on you and, you know, set up. It'll appear in Soyuz, which is our source package management system. You get also a personal app archive with the source package in it, the buildd's go on, the package, and it gets placed in the app archive. This is pretty much aimed at the Ubuntu people, but the Debian people could use this themselves and set up their own buildd's and, you know, it's sort of the stuff to do this. These kind of hooks are not the required parts in this particular sense, but, you know, so I think that was, yeah. So what I actually wanted to talk about at this slide is what we're actually doing. Can I call employees about 40 people at the moment? I think it is. Only of which 10 or 12 of them work on Ubuntu. We actually have two other major projects we do. One of them is Bizarre NG, which is the team I work for. So I do revision control stuff every day, which is kind of why I get to do Debian stuff in my free time still and not worry about it too much. And then the major part of Chemicals workforce, there's about five of us on the team, the major part is over 20 people work on the launch pad. And basically one thing we're trying to do is, it's kind of evil in some ways, but it's also kind of cute, is build a model of the open-source world for everybody to use. So let's sort of build up the foundations here. So this is kind of probably a chunky bump. The basic thing, so for every, we start off with every package in Debian, and the package sets are supposed to be the same. And for each of those, we find out where the upstream is. Who's the upstream? Where's their website? What's the FreshMe page? What's the SourceForge page? Things like that. So we register in launch pad the information about the upstream. So in particularly this case, we'd have the information about the acceptable upstream in there. Generally, upstream these days have revision control systems of their own. They might have their source code in CVS or in Subversion or any of the other kind of various things. So we take that, we register that in our system, and we have some very large servers, the warm-elm of Bum when he's in the data center, and they sit there, scanning for changes in their Subversion, CVS repositories, et cetera, and convert them into Baz repositories. So we have distributed revision control, our repositories available for every upstream that we care about. So we do this as a free service, something that known people have been quite interested in this, that we've done it almost to their archive so far, and we import the full history and we kind of go on. Obviously, a couple of times people have come to us and said, dad, can you stop doing that? I'm going to have a bandwidth, so we do. But in general, people have actually been quite happy with this, who've found out about it, because it means, well, it gives more users a chance, people use Baz or Arch, a chance to actually work on their source packages who don't know CVS or Subversion. So we do that. We also look at, say, where the FTP releases get made. And we have a system which goes and fetches those, too. We register them in the database. We know what releases there are and where the toggle was, where its details are. And we import that into Baz, too. And we import those as branches off the upstream CVS import. So for a given upstream CVS, we then know where each of the toggles come off, or where they nearly came off because they released the toggle and went, ah, we forgot some changes, stuck them in the toggle and didn't put them in CVS. That happens a few times. And we do that. We then take the Debian. And we look at Debian. We see what day-to-day is published in Debian, what versions and stuff like that. We grab the source packages down. We make branches off the upstream toggles for the source packages. We import the origin toggles. We import all the patches from it and do that. So in our revision process, and we have Debian as represented as changes to upstream and upstream CVS. And we do it for Ubuntu as well. And then we do it for Red Hat and SUSE and Mandrake and Scala Linux and Huala Linux. We do it for the whole lot. We've got some very, very big disks and some fast services. So what we have in revision control at this point is basically the entire open-source world from the point of view of Debian and Ubuntu in revision control. Once you've got this, some things turn out surprisingly easy. Distributive region control systems like Baz and Arch Linux, what have you, they do merges very easily. They do diff very easily. Because they keep a history of everything and where everything came from, even when it's cross-branched and stuff and when it's been cherry-buried. They actually are very, very good at just doing any sort of what change between A and B. So the question of what change between the ex-subplicant, pharlane, patch and ex-subplicant is as easy as the what change between the ex-subplicant, pharlane, patch and Debian and in Ubuntu. So that becomes very easy. And actually take the changes that Ubuntu made and merge them into my source package in Debian becomes one command. And this gets very, very, very simple. Likewise, what changes of upstream made when they're new release become very simple. You merge in the new upstream release and commit it. And that's all you have to do to maintain upstream. What changes have we done? You can then start looking at things. You can say, well, Red Hat have an ex-subplicant source package too and they've got two or three new patches in it. Well, you know, steal them. Put them in your own package. Make them branches of the Red Hat ones. And then when you come back come back a week later and have a look. Well, the Red Hat have made some more changes. You can merge those and commit and keep up to date with Red Hat. And then you get that it comes very, very simple at this point to keep the entire, basically all of the distributors in the world in sync just by using, you know, really good control for everything. And obviously it requires a massive initial investment to do this. Fortunately, we found a multi-millionaire who doesn't, who thinks these things are kind of cool. And, yeah, so that's kind of where we're going and that's kind of what we've been trying to do. A lot of the stuff that you've probably seen, I do. I mean, probably my most visible thing I've done for Ubuntu, rather than, you know, is the patches directory. Anybody actually here use that? Okay, so a few people. The patches directory is on the, is on my people Ubuntu, Twintal, Scarf patches. I think. And basically it's the, it's updated daily and it's the set of difference between Debian and Ubuntu. And it's generated with a prototype of this system. The real version is being put together now. I mean, we've got, we're at the point where we're important all the upstream CVS and arch-repositories and finishing off the touches for the tar walls and the source packages. So, you know, we're hoping to come along quite quickly at this point. As you can see, I'm going to do, this is what we're doing. As you can see, I managed to do an import of X up to this moment, you know, while everybody was filing in. After, you know, we've got it pretty good at this point. And, yeah. So, hopefully, this is something that's going to be available to everyone. All the arch-repositories and the batch-repositories are public. Anyone can get them. Anyone can make bunches of them. Everyone can make copies of them and sort of work on them. Obviously, because, you know, making a copy of it still includes the patch logs. It's a branch of it. It works. It changes the world from seeing everything from one package and everything derived of it just to a large farm out there of possible patches you can make and possible changes you can make. It makes cherry-picking from not just Debbie and LeBlanc, but the Red Hat-based distribution and distribution is the Gen2. We had a Gen2 developer about a year ago for a few months to write us the Gen2 import. I forgot about that one. So, it makes sort of merging stuff between various distributions quite easily. And that's basically where we're trying to go with it. I mean, that's... It sounds kind of weird to sort of say now, but this is actually the whole idea we actually found at Kinaflon originally was building this revision control system. And we... The Ubuntu stuff was always intended to be an example of how well it worked. The distro guys did such a fantastic job getting it out in six months that no one thought they'd ever do it. But the distro got released without the actual tools it was supposed to be built on, which they still billed them to the old-fashioned way to this day. But in general, it's sort of coming along now and we're hoping to let everybody play with this soon. So, that's pretty much an introduction to the thing and what we're trying to do with it. So, we have plenty of time. So, this was only intended to be a 20-minute talk. So, hopefully, there's lots and lots of questions to ask. And I can't remember to repeat. So, Jonathan, put up his hand up first and I'll go down. I'm missing that's revolutionary about the HCT stuff. Because you've shown us about how you can manage branches about patches and whatever which is all well-input but I can do that with my revision control system at the moment. What I was expecting to see later on was how HCT magically produces me a TorGZ file and a Debian patches directory and something I can actually upload rather than me having to manually apply all the patches into the source again and then, I mean, I have all my separate patches as trees. So, the question was what about its revolutionary? I mean, the stuff I'm showing there is just managing patches and stuff like that. You know, how do you actually turn that into something you can upload? Good question. I forgot to demo that one. Probably great. It's still beta software. That's loud for software. You can assemble a source package. Why is that taking so long? You can assemble a source package quite quickly. Yeah. In general, you can assemble a source package. There's obviously a bug in this because it's supposed to go a lot faster than that. It's supposed to go... Perhaps you should stop working with the wireless. Perhaps the others in the room should stop working with the wireless. It did actually. It did actually crash. I thought it would. But, yeah. Okay. So, the answer is yes. It's supposed to be... It's supposed to be able to assemble the source package from it. And that's broke. Sorry, I can't demo that. But, yeah. The H2T assemble H2T source will actually give you all the time the complete demo source package ready for upload, I suppose. And they are... That's ready. It's live. Changes you haven't committed yet are still merged in. Still placed in the source package for you so you can test them and stuff. As to how it's revolutionary, I don't think it's intended to be necessary revolutionary. It's intended to be based on what we've got now, but sort of built on... It's basically taking all the tools we've built now and putting them together. I don't think anyone's particularly... They've taken... No one's particularly taking D-Patch and things like that and tied them directly to a written process. They've had their own way of doing it. The intent is just to put it all together, basically. It's evolutionary rather than revolutionary. So what do you do when else you have a little sense of what they've got? Yeah, so the question there is that you do end up with a source package that you use something like D-Patch or simple patches on or Wig and Pen. I mean, the Wig and Pen format was kind of... Well, I had this in the back of my mind when Elmo and Brendan were discussing this and naturally they had the same idea as I did anyway. So the idea is you end up with a source package that isn't... You don't need a robust to do an advocate source. I actually think the GPR tells we can't do that. I think the GPR tells us we have to ship your original source not just a pointer to the tables and a pointer to the upstream original control systems. So you do end up with a source package you cannot load. Yes? Yeah, please. Next, I think. Yeah, just in case a certain space tourist thought of the spaceship and all his money is to be put in a big mattress that he lands softly and that's not my left for the launchpad. But every project's already depending on it. Is there a way to make it decentralized? Sorry, what's the question now? Is there a way to make a launchpad decentralized? It does not depend on a certain company alone. So the way the question there was is it possible to make a launchpad not dependant on the company itself? I think anyone who has played the news last week will notice that the Ubuntu Foundation was set up to manage Ubuntu if canonical should decide to go away which I don't think it is or if market is born if market is hit by a bus or any of the other big things. So the Ubuntu Foundation is there today. I think possibly if the launchpad became a major open source product I would do the same. I think it's already demonstrated its belief in doing things right and not just finding things. You know, on the other hand launchpad is currently a closed source software but then the issue isn't directly tied to it. It's used as a data source from the name of packages so it's not necessarily bad. Kind of connects. Can you explain how useful is HTT without launchpad? Alright, so question how useful is HTT without launchpad? HTT uses launchpad to get the list of source package names in the distribution and get the sources for them and we know where the bad branches is. It uses it just as a data store over XMRPC so it wouldn't be that hard if launchpad had managed to move it elsewhere. Lightworks also wouldn't be hard to copy the data elsewhere. Mark hates this idea. It's just the way it is. It can open source everything. You've got to kind of take the bite and I think he's aware where we've been a bit. Yes, Andy? Yeah, two questions. One is if I have some open source project which is not in launchpad is there a way for me to get or if I have a well it doesn't even need to be an open source project. If I have source product of some way it's not in the launchpad but I want to get want to use this tools. Is there a way for me to do it? So the question there is if you have some software that isn't registered in the launchpad or it's closed source or anything, is there a way for me to use these tools? The launchpad is just a web app. You can go there and register your own software. It's not limited to the stuff we've registered. And I can do it also if for example I'm not allowed to share this canonical. Can I do it with my own servers? I think else there is there's no reason why I couldn't today now. For example, if I download some shady case I'm definitely not allowed to share this with anybody else. So just a good example. There's no decision being made there. There's no decision there. I think that you very well could decide that people that want to do proprietary software may not be able to use that. That may be a that may be a decision that canonical may make. We haven't got the definition yet. My general feeling at the moment is it's the system is designed for open source people so proprietary people can kind of do their own. What if the software is not proprietary but you want to work and you don't have internet access? Because so the question there is what if you don't have internet access? You don't even have internet access to contact the launchpad to get the source package names? Well, generally this is kind of where do you work. It keeps a local cache of everything you've worked on. So everything you've worked on is available on your laptop. And once you've worked on something you don't have the launchpad at all until you're ready to commit it. So publish it sorry, you can even commit to your laptop. Let's say you don't have any internet access at all and I don't know you get your Debian CDs or you put the CDs through the mail or something you don't have any internet access at all. So at that point the question is what if you don't have internet access at all well if you don't have internet access at all you're not going to be able to get the new upstream target anyway so you know you're not going to be able to see what patches are in red anyway so it's not really right here. Did you have a question earlier? Yeah but I'm not quite clear whether you're keeping the actual pristine original tar balls in subversion or if you're just keeping the set of files. So the question there is do we keep the original pristine tar balls in or the set of files that are in them? Yep. We keep the set of files that are in them we don't keep the actual original pristine tar balls but what we do have is the record of what its MD5 sum was and what the stats of the files were in it and we do something very very sick to ensure that when we reconstruct the original tar ball it has to say the MD5 sum has just not been modified. Like putting the tar file and going out on a tar file and text editing it. It was about five o'clock in the morning and I've been clubbing it works fantastically up 16,000 source packages it's not broken yet. Okay we will call the set saying the D package and G or so. This is not related to D packages nothing here. No but it's a way of finding code just of the clear design. Do you have another question? Yes the other question is some easy how to for if I'm now a dependent management of some package what's the weight due to the use of it? Because usually I don't get you and I ask you okay please tell me how to do it so it's where is it available? So the question there is there a how to how to do this? Not today because obviously this is still being written we're still crashing out when I try and do demos. It's we have a kind of rough I'm going to find to Brazil pretty much after this conference for three weeks and two weeks I don't know how to actually know I'm the world's least organized person and one of our aims there is to put a lot of this stuff and finish it off and get some polish on it and it will be completely documented I mean I actually like writing documentation which makes me a very strange person so there will be tutorials and how to's that will come with it to show you how to use them. Joey Okay where I'm at after this talk is I'm trying to find what this will do for me what I'm currently using doesn't do so I might have to briefly explain what I'm currently doing keeping things a version I keep full sources I keep all the upstream versions as a branch and so on so I can get all the history I want I can pull files in one I'm not particularly interested in distributed revision control as such so I get some questions and I'm not particularly interested in separable branches as such so my question is what else can this do for me if anything? So for Joey's there just explained what he does now and we also know what else it will do for him Do you work with these source packages you work on just yourself or with other people? Both So I think the main advantage to this way is that you can work on a single patch with other people without the conflict on a single patch you're already ahead of the curve at this point you're already using things in revision control so you're already one step ahead of a lot of the other people that this is aimed at The one thing we can do of course is we can and we do import the depth of stuff from your subversion repositories and make it available for anyone else as well and this will let you pick those changes up that say a devian derivative have to make a devian installer to make it red and blue because that's their company colours you know there are various things there it will let you do What's your next single once you've had things that was more about the HCT side of things Yeah the HCT itself the main thing it will let you do is it gives you a method for taking patches from other people and updating your patches based on what other people have done and seeing what red had done I don't think it would be DI but what we're going to have done with DI and with DevHelper of Collins with the patches back and it gives you a tool for doing that I think it's probably what it would do for you it gives you a tool for what's changed else what not what I changed was other people changed and can I have it back you know it gives you a tool for doing that I would say is what this would do for you Anyone else? Silent Oh there we go So you said that you had the source for all the open source stuff in the world or something like that How big is it in bytes? So the question there was how big is the source of the world I don't know what the numbers we came up with the current set of just Aventu with no differences was 700 gigabytes I think it came up to 4 to 500 terabytes Big disks did I mention that and we have that I mean the disk base that's like a tenth of the disk base of the song system so it's not really that No question Are you actually working for Canonical or for something like Secret Service I don't know We're evil apparently So the question was there instead of mirroring Once your repository is being mirrored it's available If you go to Arch.Aventu.com today you'll find the Bazaar price of everything we've imported so far that have been published and been checked to make sure and you know at that point you can branch off it yourself and add patches and commit them back and yeah certainly at this point you could once it's been imported if you wish to change to Bazaar I mean the only other reason we're doing this of course is we're funding revision control systems by Bazaar so if the whole world stops using Bazaar to do revision control we win I don't quite know how you make money from that but this is a generic problem with Canonical we do all this really cool stuff and then we sit next generation after everyone has switched yeah problem is there going to be a change of issue with Bazaar, Bazaar and G or are we just kind of working together to learn? Ah, so this is quite a good question is there a change of issue between Bazaar and Bazaar and G Bazaar and Bazaar or Bazaar and Bazaar and G or however you want to call them so as I said in the beginning Bazaar itself is a fork of TLA which has got continually improving user interface and some various changes to the back end Bazaar be it Bazaar and G I think is a brand new revision control system that steals ideas from pretty much all of them out there it's reasonably influenced by BitKeeper and by Subversion and Darkz with some cards thrown in and some other stuff so how is there a change over issue between these two? Well, no I mean Bazaar and G is a Python program and Mark likes Python the whole world should be Python it's a pretty good language good fun but Bazaar is a C program however the evolution of both of them is Bazaar can be basically a toy development project where we can test out new ideas and once those ideas go stable they get merged into the C version and the C version kind of is evolving towards what Bazaar and G is evolving towards so if you can imagine they're starting out sort of here Bazaar and G is going that way and Bazaar is kind of moving towards it and Bazaar has all of the repository upgrade tools in it so when Bazaar sees your repository isn't old it can kind of help you upgrade it you know help you upgrade your working trees and stuff like that so there are conversion tools as part of it the change over will be reasonably painless at this point because both tools will support that repository format at the point we do it as to which one will win to see all the Python nobody knows we haven't made that decision the two people in charge of them haven't been told which one's in charge it kind of creates a healthy competition between Robert and Martin to kind of which one's going to win and which one's going to get the better the Python invitations seem slightly in the lead today but we'll also see what happens next week or the week after so yeah the evolution towards both of them Bazaar and G obviously goes in the direction it wants to go but the C version is you know arcing towards it and the advantage that Robert has is all he has to do is take what Martin's done and just implement it Martin has to do the really hard thinking which of course is nine tenths of the problem so Robert just has a simple matter of programming which as anyone will tell you is not exactly a very acronym anyway any other questions what are we doing for now we have about six or seven six or seven minutes is there anyone else anyone else yep so actually it allows you to have a demo source package out of your stuff does it allow you to do the reverse or do you have to rely on that being done by a large part so the question though is actually it allows you to take a bunch of branches and repositories and make a demo source package out of it does it allow you to do the reverse hmm assemble assemble takes your branches and makes the source package out of them the question there becomes how do you you know are you talking about taking existing source packages today and importing it or are you talking about creating a new source package because obviously creating a new you know about taking the business source package I mean it's a wonderful question because I have to square the answer is at the moment the tool we use to do the imports is actually proprietary canonical at the moment it's not a I think so I'll explain the reason why it is the first that's probably the right answer and then kind of where we're going with it the reason why is because Launchpad is intended to be and today if we gave it out to everybody everyone else would go and import their source packages and put them on other systems and that would defeat the entire object of what we're trying to do because all the Arch IDs would be different perhaps lots would be different and the way Baz works doesn't allow this because it's based on TLA but RNG is fine I mean it allows this so it's kind of it hasn't been released simply because at the moment it would cause more chaos than it would do it's not it was actually it's got some interesting things but in by and large now it's not it's not released today it's not going to be released tomorrow but certainly it's not code that's intended to be always kept under the terms I think Mark wants to keep a competitive advantage I suppose is the right term for a short period I mean that's the same as Launchpad in general certainly any source packages exist we would import for anybody and we make it very easy but the code itself isn't actually going to be released on the short term scale I'm on the long term scale I don't see any reason why it isn't going to be released so I guess I should point out to anyone who feels a little bit uncomfortable with that that it's certainly possible to import your code into original control using CVS Subversion or RG using tools that are indebted yeah totally it's totally possible today to import your code and we can use that and we can import your packages even yeah it's totally possible today with existing tools to import your code into original control and actually we can use that as well so it's not we don't mind people doing that do you use CVS to launch and then use ACT on that yes the other thing that's worth pointing out is that once you've got published RGAP with single IDs you can branch and download them to error positively yeah just like I said one thing about BAS is once you've got it published it's got IDs which are constant so copies of it and varieties of it and W gets of it and I think so etc as our copies they both are compatible with each other patches from either one can be merged into each other once it's published it's free to everybody okay I think that's pretty much our time isn't it yeah so yeah that's basically what the stuff I've been doing hopefully it might be interesting some WNP people when it's ready some of them it might not be but it got me to come to this conference for a week so I'm kind of excited as well so there we go thank you if anyone actually wants to sort of chat to me I am going to be around for at least for the next six, seven, I don't know maybe we'll get it done okay thank you so you're still not seeing this as an idol you're only going to stay up for six hours