 OK, so for the last event of the day, we've got George Castro here from your own article. And he's going to talk to us about collaboration between DeWintu and Debbie. So everybody, welcome, George Castro. Thanks, everyone. Just a little bit about myself. This is my third debt conflict. And I'm really glad and honored to be able to speak in front of you today. I want to talk about something that's really near and dear to my heart. If you don't know who I am, I work on the community team. Specifically, I'm a general developer in relations with is our upstream. So our loans are KDs, and Debbie are being our most important upstream. It's important to me that the sort of collaboration between our two products is in a healthy state. So this is going to auto-spa my slides. So if you want to talk about today, since it's between our two projects, it's getting a little bit long. I really want you to talk about the past, unless you want to bring in the discussion at the end. But there's a lot of great stuff that are doing today. So I would really concentrate on that. I want to communicate to you why these things are exciting to me. And also, because we want to work on the future. And of course, the fossil fuel relationship can be a mutual respect of collaboration. So what I exactly do in my collaboration, to me, I think at any point is important to our relationship. There's a lot of things where people use the word collaboration. They don't really explain what exactly they're talking about. That's having new members and developers participating and debuting and participating in that comp. So we can talk about how we can choose that effective projects, how we can work about it together. And collaboration with ODC, I have a bullet here. This is from a fan base where I communicate here that the products are so large that almost 1,000 developing and developing. So it takes to recognize that sometimes you're going to get a package against every issues solved. I think at this point, some people are going to say, which one you get the small amount at that time because all the issues are fixed, right? But Zach, to just talk about it, it's not a good idea. You want to get the consensus that it's not true for entertainment. And it's too difficult, right? A lot of the work we do wouldn't be possible if people didn't like to cooperate with us. So the first thing I want to talk about, which I'm really excited about, is the derivatives front desk. So this was a practice started by me to basically be a one stop shop for derivatives such as I'm going to learn best practices on how to work with Debian. My personal interest is patches and bugs. So in a few slides, I'm going to talk about some of the patches that we found around and bugs that we found laying around. Shouldn't be laying around. But the derivatives front desk gives us a good place where we can start working that process. And it's also a really great place for new contributors to get started. So basically, I want to be Debian and it would be an exception to others. And let me go back, right? So Debian has other derivatives, right? Someone can say, well, I started a Debian derivative and I think it would be a great idea if I did this, right? You can say, well, I remember when George had this really bad idea and it was total fail. So learn from my bad example. And we're seeing great anticipation from Ubuntu and Debian. I think there's a few next sense of folks in there. I don't know if any of them are in there. So, but this is really great because it's you and I can start to get other derivatives here. So I'm really looking forward to seeing the work that goes on in here. And of course, this is on hash Debian dash Ubuntu on Ubuntu. So this is my favorite thing when people ask me, how are things going with Debian with you guys? Are you guys still like hitting each other? I was like, the relationship gets complicated because when you have over a thousand people in one project and I'm not sure exactly how many people we count as Ubuntu developers these days, we've had many to many conversations. There's really no simple answer. People automatically assume that's bad, right? So when they say, how are things going with Debian? It's complicated. They automatically assume that it's like their experience with a boyfriend or girlfriend where it's complicated. But it is many things. So there's pockets of good things. There's pockets of bad things. And I don't think, I think it's a waste of time to try to reach this nirvana state of things are going to rate. No matter what we do, things are always going to be complicated. So we're going to have pockets of good things. And I think the key there is to sustain the ideas and the ways we learn from those good things. And there's pockets of bad things which we can learn and move forward. And of course, help other derivatives not fall into the same mistakes. But this is active work. You can't just kind of assume that, oh, everybody's going to try to do this thing. It takes literally everyone who is involved in the project to try to make sure that that doesn't stagnate and end up being bad. Mythbusting. So this is my second favorite thing is I always tell people, hey, so what are you doing next month? You want to have a beer? I can't. I'm going to DevConf. And they give me this look like when two people go to DevConf or they kill you and display your brief or whatever. And as Zach mentioned this morning, my very first DevConf three years ago, I was a little intimidated. I was like, well, as Zach pointed out this morning, he's reputation that some projects would have. And I was really concerned. I was really scared. I was like, if I wear my Demian T-shirt that I bought five years ago, will somebody think I'm trying to be a poser or what? So people ask me this all the time. So what's it like to go to DevConf? And I was like, man, some of these people are the best drinking buddies I've had in a long time. So I think, and you know, Boutou can have reputation as well. But I think one of the things that we're all starting to become better at is forget the myth and just work on fixing the problem. Within the people I've talked to that started in a Boutou and come to Dev, it doesn't match the myth. So I was just at a sprint and I had a person from our kernel team, he came up and he was like, man, I'm getting into the Demian Maintainer process. He was like really excited. So I love to see things like that. And he was like, you know, I had this preconception in my head that, you know, it's gonna be bad if people are gonna like yell at me and all this kind of stuff. But you know, I find a sponsor who's willing to help me and I'm getting a lot of stuff done. I think that also too, so a lot of this is the internet's fault because they have this view on our projects. So it might be this myth that there are always bad things going on. So when Zach did his little survey because he was attending a UDS and he said, I wanna know what your relationships are with Ubuntu developers, et cetera. And there were a few teams in there that I hadn't heard of because people always concentrate when people make mistakes, right? And usually when people or teams make mistakes, you hear about a lot, but you never hear about some of the teams that are out there that are doing it the right way, right? Maybe some say, you know what, I either carry this patch or I can fix it at Demian. But a lot of people are just out there with their heads down, skating hard, trying to do the right thing. So something I personally try to do is instead of getting involved in these conversations where people are flaming the people who make mistakes, I'm also trying to encourage people who are at least trying to do the right thing to continue. And we're also proud of our contributions. The gentleman, I don't know if he sat out earlier who said, I started with Ubuntu, and now I'm involved in Demian. We're really proud when we see the new list of DD and I recognize the name, or it's somebody who started. Just a quick survey, how many of you like started in Ubuntu and are now contributing to Demian? Well, okay, there's a few, good. So, we also have O2, I'm working with Demian. This is pretty interesting because usually in the Mo2 channel. What's Mo2? Oh, I'm sorry, the members of the universe. So we divide our archive into main, which is basically what we ship on CD. There's universe, which is the rest of Demian, and then all the illegal bits. Moral is the same. So, one of the great things that we're seeing lately is someone joins a channel and they say, hey, I wrote an application and I want to get this in Ubuntu. And one of the very first responses is, have you talked to someone at Demian? And they either say, what's Demian? Or they haven't. So usually that's when we have contributors step up saying, look, if you want to do this the right way, you need to talk to Demian first. So, I'm really happy for that. I think a lot of people think that it's a top down kind of idea, but to see that down at the contributor level with Mo2's, many of whom are now getting more and more familiar with Demian processes is encouraging to me. We're also making active work on pushing patches upstream and to the end. So, this is actually gonna be a little bit of a question, but I'll show you later, I'm doing a lot of work. I'm trying to get patches to be visible both to upstream and to Demian. And I got the launch pad guys to basically write me a little view that all patches sitting in launch pad that have not gone anywhere. And unfortunately, the number was pretty high. It was like 1,200. And this was really discerning to me because we talk about how we wanna lower the barrier, right? And it's like, if you wanna contribute, send a patch, a patch somewhere. And then someone goes sees a talk from Mad Dog, how they get pumped up, get back. They do a little Python patch, patch to launch pad or the BTS. And then it goes into this black hole where the Higgs phone is. So, I created this, I asked them to create a view that showed me these patches. And now we're actively working on getting the number down to zero. And it's not gonna be a zero, but what we can do is fix the processes of what happens when a contributor, or even a computer, contributes a patch. I'll leave you with that a little bit. We're also seeing greater participation by DJs and DMs as a reference. In case you haven't heard, if you're a Devian person, you always have an open invite to come crash the Would You Never Summit. We like to have the points of views of the Devian developers in UDS. So, usually on the Thursday, I always run a session called the Devian Health Check where a lot of people coming in, DDS, people who are Ubuntu developers who are keen on working with Devian, you basically go around the room, it gets a little heated. But you have to have those discussions if you're gonna fix problems, right? And we also discuss about things that we are doing, right? And how we can continue to do that. So, upstream relationships is also something I'm very passionate about. Particularly because it's opportunities to get workflow right off the bat. So, if you have an upstream that shows up and says, hey, I'm interested in getting in Ubuntu because we're server-based upstream and LTS is important to us, that to me is the critical point where we educate that upstream on how the relationship with Devian and Ubuntu works. Like, for example, do you know if you talk to your DD and you have a relationship with them and or your Ubuntu developer that we can minimize deltas between the two releases? Generally, upstreams want to do the right thing. I've never been upstream. It was like, oh, no, Devian, I don't want to be in that. Who says that, right? They want to get their stuff to use it. Okay, right. Generally speaking, the upstreams care. So, okay, let me rephrase it. Upstreams I've talked about that really want to be successful. Oh, boy, and you have to walk in at some point. But generally speaking, they don't know the process, right? I work on this document, wiki.ubuntu.com slash others. And there's basically two sections. The quick and dirty way which involves setting up their own app repositories and PPA stuff. And then there's a long-term, smart way, right way to do things, which means talking to someone at Devian. And we have a lot of contributors who, when an upstream comes up, they say, I have no idea how to talk to Devian. We have people that step up and help start that process. So, and at the end of the day, it's convincing upstreams that it does work. We have this old-school mentality that there's upstream and then there's a line and there's the distribution, right? The software now is getting us sophisticated that you really can't, you can't ever have these islands of, well, you know, I'm an upstream of stuff. That's your problem. You know, we'll have to distro, this won't be your problem, right? We need to start meshing those together because it's becoming more like an operating system than just a distribution. So how am I trying to measure success? I had this awesome idea which ended up being totally horrible where I was like, if I figure out whatever the magic number is of our attribute to Devian, then I can measure that and then I can just measure it grows or doesn't go down. So, thanks to Lucas Newspom it was actually like way smarter than me. We started measuring things like originating to here are that we forwarded that would be interesting to Devian developers. We started asking people to tag their patches that they sent to the industry there. And I think, oh, awesome, 1386. That sounds like a magic-ish number but it's a lot more complicated than that especially when a lot of the Ubuntu developers who are also with Devian say, why would I go through all this mess or just send Devian? And I was like, well, that's so fair. I can't measure it. How am I supposed to come up with my number? Right, and we have Ubuntu user tags where we keep track of all the patches based on leases that we do. So for halfway through a cycle, we say, hey, wait a minute, the numbers are down. So please keep using your tags. Started to measure who's doing the amount of work because I wanted to see a nice mix of people here not just canonical employees or whatever. But again, some people weren't using these tags so it became very difficult for me to try to figure out why I'm even trying to have this magic number when people would just be doing the work directly in Devian. We have a tool called Harvest which looks at upstream bug trackers and their patches and we can do this for multiple distros so we can see if Fedora is carrying a patch and we should do our bugs that are fixed upstream. So if I can gather all that, I can come up and help add to that magic number that will solve all those problems. On the right here, on the QA page, we have links to the bugs that are reported in Ubuntu for that package and we're also showing you the patches, right? Looking good. On our QA pages for Ubuntu, we have the same thing, doing everything to lower the entry to show patches. This is the view of what I was talking about where you can take a URL for any person or any project you have to attack a plus patches at the end. We show you all your patches, right? Amazing, if I could just get upstreams to look at all these pages and we index every distribution, it'll be great. It'll be great. This is how we're doing with Operation CleanSweep, right? So we've at least 2,200 bucks. We've gone through 378 of them. 90 need work. 164 were able to submit direct stream. 51 were able to submit to Debian. These are the ones accepted and accepted by Debian and the rejected ones because I wanted to get a feel for how well are they doing? Are these patches that are sitting in Launchpad worth the effort or are they all prepped? So some really great, right? However, some things just aren't easily measurable. There's no way to, there is no magic number and it took me some time to realize this because I put all this work into thinking that I would solve the world's problems. Ends up, I'm not that smart. So then call it, the highlights are mine here. Blocked this recently where he basically said maintaining grub two and someone basically just emailed me and told me, hey, you're really great since you're a co-maintainer to take care of these issues. This is something I can never measure with a magic number. This is something that involves the personal relationships that we have and that we maintain in free software. So I've come to convene that these numbers and all these great tools that we're making are very useful but we should use these as guides and not just, right? It's like Steve, you're in big trouble. Your numbers are 20% down from last cycle. But what does that mean? And we also know that there's thousands of people out there doing things that might not be measurable. There's people out there who might be introducing people to each other, right? How do you measure that? You really don't. There's the person who stands at a Debbie and Booth for six hours straight and falls over. How do you measure that? You don't compare it to a developer contribution. So these numbers, it's sort of like a Sisyphean task. You guys, the myth story where there's a guy, he got punished by a God and his job was to take a rock all the way up this hill. And at the very top, it will always slip and fall back down and get all depressed. So you would have to do that for eternity. So these tools and things like that are really good to measure but it doesn't replace the kind of discussions that we'll be having at events like this and you just, you know, open those shows over. And at the end of the day, the work on the culture is a better payoff, right? I don't think that sitting there staring at, trying to get this magic number is as important as to say, hello, welcome. Oh, you're a new Bluetooth computer? Let me tell you about the importance about what it's like to work with Debian and why that is. So I think in the long run, it's better to use work on the investments of the people. Sometimes people ask me why why Bluetooth doesn't really have like one person who's the Debian relationship person. And that's because it's every developer's responsibility of the project to be that person. So in the future, there's some interesting challenges here which I think are very important. As Mark showed earlier, with an application, we're starting, canonical, it's starting to last time and it's a project, excuse me. So how do we work this workflow, right? I'm sure some of you saw that, I'm going to be in Debian. What kind of work does that have to do? And a lot of ways, there are things that we've learned here as far as it takes to work with upstreams because we're not, Ayatana, the book, the Unity guys, I'm sorry, are kind of their own upstream and me being on the platform team, we have the same issues. So there are times that we have to distro patch something and then ensure that the patch gets upstream to someone working at my same company. A lot of things that you can learn there as far as workflow goes. And Debian is the hub for derivatives. Tell me if you share this nightmare. Probably not. But you have Debian, let's say as a hub and you have different derivatives based on Debian, right? And we're actively working to ensure that this is working. So I have this, okay, this is a pretty big night. Is that there's someone at this derivative over here who's fixed a bug and maybe they don't know how to get it back. So they set it up and then you have another derivative who might face the same bug and are they looking? Is there a process where they can get the other derivatives that are facing the same problems, right? Because every other day, what we don't want is every derivative fixing the same bug over and over again, it's a waste of effort. So I think what excites me about the derivatives is it's an opportunity for us to figure out a pattern bug workflow so that we can make it efficient for people to make stuff back and forth, right? So you have the hub and things going like this and that. And it's also an opportunity for us to reinforce the color of upstreaming things to Debian so that we're not carrying the big dolphins. These are some people who've done some really interesting work. Without Lucas basically defeating me every time there's an issue in Debian and I wouldn't be here. So I'd like to thank these people with one foot in each project. And there's also a lot of people here who I might not know about or things like that. And that goes back to we should be reinforcing the people who are doing the right thing. So there's too many people to list but we can always never have enough help with people doing this because both of our dynamic projects are very large. Well, there's 29,000 packages this morning, right? You're not gonna catch them all, they're not like Pokemon. So it takes everyone's effort to be able to catch this stuff. So here's some Ubuntu developers who are here. You might recognize some of these names. You just wanna make sure that they're up here. If you're a DD and you're looking to talk to someone. Like I said, I'm one of the people who's at Debian.com address. And I was looking for feedback, good or bad so I can help get the word out on the stuff that people are doing. So I purposely kind of rushed to these slides and I didn't have any slides because I didn't want to bore you, I'm kind of boring. But I wanted to do is open it up for discussion on those of you who have had experience working with Ubuntu, good, bad and just basically leave it open-ended for us to talk about where we go from here. Anybody have any comments? First goal, accomplish, not getting killed, all right. Wow, that's cool, funny. Yes, so in fact, I just wanted to thank you because so I went to UDS to present Debian Views on our collaboration with the Worldways and I asked Jordan to do the same and he was actually scared of getting killed here. And I'm actually very scared. I'm actually very, very happy that you are in the end set to come. And I think this is the way forward not from the interest of Debian, not for the interest of Ubuntu, but in general, it's a result. Yeah, I mean, to me, there seems to be a lot of people who have been working with Ubuntu in the past. So we had our Debian health check at UDS and then I was like, you know, since Debian Conf is in the middle, what a great time for us to sit down again and look at our progress from the issues that he figured out how to assign me work items, which doesn't really help me out a lot, but yeah, you know, the Debian Conf and other conferences where we have strong Debian participation in Ubuntu Faustan, for example. There's no reason people can't get together and do a little pulse check. Ah, she's my favorite. I guess I'll stand for that video. So what were some of those work items and what is progress? I know that you talked about a bunch of things, you talked about some of the metrics, but also how they're not left. I guess like, if you don't want to answer that also after this other question, like what's a recent happy story that's longer than... You can think about that too. Let me address the first one. I think one of the concerns Zach told me in a way is that sometimes I think people lose the fact that we're probably built on Debian and that people say sister projects and stuff, but I don't really know the analogy there, but like I said, it could be very difficult when you have a new year that bought their Ubuntu machine somewhere and they have no concept of Debian. But I don't consider that a bad thing mostly because I think the people that I would like to get to Debian the most are probably the more advanced users, the whole built by experts deal. So someone starts off using Ubuntu and has no clue what Debian is and finds the link that we put in the browser or, you know, the source code and figures out where it is and ends up at least looking at Debian and looking at how to tribute. Then I think that's a user education thing. So I guess I asked about what the goals were and how the progress is and it sounds like there's feedback. It sounds like he said one of the goals is helping people find Debian and one of the things you've done recently is test link in the browser. No, it's actually been there the whole time. It's just very good. Actually, we don't bury the Debian one specifically. Our bookmarks are the kind of nested hidden thing. One of the things the page I'm really proud of is the Debian Ubuntu story on Ubuntu.com that every time I refresh the website someone drops it and a whole bunch of file bugs and I'm going to kill me and then I have to get it back. But yeah, I mean, we've had that there. It's a tough thing to communicate, I think. I think what's important is as long as users are people like us who are aware of where the contributions come from then we need to do a better job recognizing people for that. So one of the tasks was maybe perhaps we should be talking more about some of the things that we get from Debian that are useful. I don't think standing on top of a hill saying we're built on Debian or whatever. I think as long as users understand how things flow is a good way to do it. A lot of it is figuring out how to do it subtly without spanning. Hi, I know of some cases of people forking packages out of like not using the Debian package but or contributing to it but just forking the package. And I've seen that both in users and by multiple, I think. And by some core supported package. I was wondering if there are some criteria by which you can do a fork or avoid a fork. I mean I've even commented that Debian is not a combat, it's no success. Right. Before I ask we smarter than me to answer this question that here's a good anecdotal story. There's two birds with one stone. We had a relationship with an upstream who wasn't very happy with their packaging in Debian but he had a personal relationship with someone in Ubuntu so they were just going to change it. It was an excellent opportunity for Ubuntu developers to say hey, I already have a personal relationship with that upstream and believe this is not the way they're moving and maybe we should try and kind of read from scratch and he did do you have any comments as far as the fork packaging goes? Oh, I'll field that one. Yes. You have been noticed. So in answering this I'm going to refer back to one of your earlier comments about how is the relationship between Debian and Ubuntu, it's complicated. Just as Debian is not this monolithic hive mind where everybody's on the same page about what we should do with packages or how we should interact with Ubuntu and it's a complicated relationship. The reality is that on the Ubuntu site as well it is a community project with a number of developers who each have different opinions and it comes down to personal relationships and trying to hook in and that's something that we should try to do on the Ubuntu site to try to avoid fork wherever possible but you have a disparate group of developers on the Ubuntu site and sometimes people fork for all the usual reasons that forks happen and above all I would hope that not get in the way of the overall health of the Ubuntu Debian relationship. Zak mida is sorry, Zak mida pointed this a plenary earlier that I'd like to refer back to the answer to that question as does any developer decide to apply patches to a package rather than getting their patches upstream and again the answer is as complicated as there is a makes sense upstream for one reason or another. Sometimes upstream is just kind of slow right now sometimes the Debian developer just kind of sucks. The answer is much the same when you go one step down the answer it's a lot easier to look into specific things if there are individual cases you're concerned about and it's kind of a lot easier to have the discussion about those specific reasons because it's just to keep on this thing about forking I was wondering if you could identify a few differences in policy or strategic differences between the Ubuntu project and the Debian project that generate some of the issues over which one considers for instance forking the packaging. Because policy is one issue where you might not be able to reconcile. I'm going to answer to this but before we start I think for a lot of packages particularly what we ship on economic type packages we usually just direct from upstream and I'm just going to actually answer your question. So I'd say the two primary causes of Debian which are unavoidable on our example are number one that Ubuntu is split into a main and reverse so that we try to keep them recommended as complete and that means we have to change the dependencies and recommendations of many packages to stay within them. The other is that we have certain properties such as Firefox that are kept with a different name and when you do again change those to Sorry me again. As I understood the original question packages and forked distinct from packages that have been branched and have changes in the Ubuntu package but still share the overall packaging is that I mean there are different issues there we're always going to have to carry some patches but is that actually your concern or is I was actually referring to both one of them was one of the packages that was branched but basically I never learned about it so Ubuntu shipped an obsolete security vulnerabilities in the universe so after several mails in the end I counted with the security team of Ubuntu to say yeah please there's no reason to do that and the other one was about a non-universe package main package that was created for the KVM ship MT binary for a while My experience I used to be far more critical about the Ubuntu Debian relationship two years ago from my experience I still have one little minor concern and that is what the last time that I got patches from somebody who was immortal the patch was one giant monolithic patch that included changes that had been changed for my conversion and it was a patch against the last time I guess Ubuntu sent or something like that and it was very hard for me to actually apply it because it contained my patches, things had moved on is there a process in Ubuntu for creating say a upstream branch and rebasing patches which is kind of what I came to do with my experience I can make a stab at things like that number one if you get something like that then just push back there's no reason that the burden of trying to unpick that sort of thing should be killed on you and there's almost certainly somebody who just doesn't quite know what they're doing yet but it's far better to educate than to kind of accommodate secondly revision to show practice is very widely as I'm sure you know in Ubuntu just they don't tell me a number of people sorry I got on the back of the camera just realized a number of people do create branches or use quills not as many branches as there are branches but a number of people have approaches and in some cases it just depends on how deeply involved we are with the package it's kind of like in your case the result was probably using we have a submit Debian script which takes the patch if you're supposed to you can see how it goes from there it's kind of trying to encourage people to at least get we'd appreciate it just as much I'm going to go quickly for your feedback here I'm a little bit concerned about some of the sort of default proprietary actions of Canonical for example, apparently there was a great deal of work to get that open sourced I'm a little bit concerned about the cloud software that's currently being developed for example even some of those kind of bills not a deal of priority some of those product practices could you address that a bit yeah, so I'm not I can't comment intelligently on what our plans are for the server side software for Ubuntu 1 currently it is working on here as far as the arm build is there oh, that's Loica oh, Loica is right here this is the guy to talk to I'm not quite sure I understand this I'm not quite sure I understand the problem you're having with the ARM 7 but basically we're doing builds in a very similar way than Debian with a different optimization level why is it done in Debian though? why isn't it done in Debian because Debian cares for all the machines like I don't know open moco phones or NAS devices or things like that while the Ubuntu port was specifically created to target networks so like more higher-end ARM devices which were ARM v7 and so if you go for ARM v4 v5 you kind of lack instructions which make it go much faster actually there is a new Debian port on its way it's not official anything but there is research going on in Debian port for hard float and because our float already has a high requirement on machine square it can run it would probably run quite faster than ARM or soft float which we have right now any other comments? so man first I guess so I noticed that a lot of the questions about branching packages and so forth between the projects a lot of these questions were phrased in terms of what is the policy or what is the process around this what's the overarching standard that governs this but as Steve pointed out with these are two complicated projects made up of lots of different people different behavior, different patterns and we won't always have an ideal for how things work that we can say this is what the policy is but if it helps the official policies don't do anything foolish if you notice anyone not adhering to this official policy the right thing to do is to tell them that you want help working with it if there is the data.buntu.com the hash of data.buntu on our FTC this front desk there are lots of places that you can go to get help with this and please feel free to use the address I mean don't think that I'm going to tattle tail on you at www.buntu.com and then we'll it'll be back the whole point of having the address is to give give dds an avenue where the game brings up without having to resort to flaming people so this is very interesting I just wanted to show you actually you have I never went to buntu but I liked one feature this separation between main and universe it caused when the universe was buried in bugs because transitions weren't synchronized not like in day 1 trying to get ready I wonder if such feature will prevail so we could use buntu as a testbed can you rephrase let's say posix compliance compliance chats main part of buntu was probably transitions to be dash compatible but then universe wasn't and it just transitioned because it was main goal of main and same with python and other stories but I created this feature for us because it's a testbed I wonder how is it working in booms main and universe so I think that's one of the things oh I'm sorry sure your answer will probably be a lot to my ears so as I understand it you're asking about the relative efficiency of making wider engine changes making broad rather than deep changes to packages is that critical transitions from one package version to another which is critical for main also for universe and multiverse which is not supported by canonical but supported by community so with this interaction between canonical and buntu community in terms of transitions so we've been looking at we've actually been looking at flattening like the men and universe separation anyway it was good where it was simple in 2004 when we started buntu it's a bit more complicated neither of all these different derivatives of buntu that are maintained in our archive and doing all kinds of other things but the the guys who maintain sorry the people who maintain universe and multiverse have generally been very organized about doing transitions in a timely fashion there are some things through of course but for the most part they keep very much in top library transitions that need to happen and that kind of thing it's quite impressive sometimes the main difference I think between Ubuntu and Debian there is that in Ubuntu people are officially entitled to make broad changes there are also wide swith packages trade-offs of course is that we have fewer experts in individual packages so there are strengths on either side Stefano's initiative to try to get enemies by debugs I'd hope that things like transitions would be considered there other kinds of broad changes in a little bit more agile in that respect but it's a trade-off between deep efficiency and broad efficiency does that make sense? are you specializing in deep or broad and flat? in there any other comments? so that came up to me about an hour before my talk which is why this is in a slide Medi did I pronounce that right? today I don't really like how patches.ubuntu.com is showing me the patches so I'm working on this and I thought it was it will be useful to show here but it shows a given package that's that fun thing the change log, the links to the pts and the disk from Ubuntu but what he does here which I think is cool is you can do it per file here or if you can click the download so I thought that was very interesting it's really good I think that people are thinking about how to make these tools more efficient and you've all seen the ultimate database right which is really useful when trying to find the magic number say do I'm sorry this is ubuntu.diff.med but this is a slash beta which I don't know if you want people going there yet but no sorry patches accepted any other comments or questions? I feel five minutes too early yes sir so I don't have access of experience interacting and no amount of patch tracking I've got just one question do we actually track how many ubuntu developers have become uploaders in packages because I know that there's several packages in ubuntu that I have adopted in a way in Demi to become part of that maintainer I was curious if there's a relatively active flow of contributors in ubuntu becoming DMs or at least being part of the uploader flag of maintainers packages uncollected legally tamed packages so we are I think we have observed that there is actually a flux of people from ubuntu becoming DM or DD in values ways there is a very interesting master thesis work by Gauden's styling probably around here where you monitor the change in the number of debian news of the first release of ubuntu and the change in the additional developer workflow in debian showing that it's kind of compensating by people coming from ubuntu then we have list of individuals which came from ubuntu join debian look at the listing so we are doing that in an empirical way if you want to enable us to do that more precisely I think you should just settle in something specifically like saying that if you apply for an M coming from ubuntu just use your at ubuntu.com others and then that way we can have some more precise statistics and that way of course actually that's great I have in the ubuntu bug control group on launchpad and if you're a debian developer that's working on a package and then you find a bug in launchpad you go in there and you don't have any help maintainer of that package in debian just kind of hold up me and I'll give you the proper permissions to be able to fix the bug Lucas can you just make that automatic please every time we try something automatic in launchpad it's not a good idea to be honest for me my selfish reason is because that way I have I can talk to that person and I kind of know hey what package are you working on but generally speaking when it comes to things like that we want humans to make the definition yeah so more generally I think but more generally that's what would be great from to be more feedback on how to improve procedures to contribute to ubuntu I'm not talking about everybody coming to develop that but for example many people are interested in pushing specific versions of their packages to ubuntu and currently there's no standard procedure for that and you could install ubuntu dev tool and use weekend request sync for that it's not documented properly and I think people say like an easy way to do that would be really helpful to know what are the things that cause this problem for the dev developer another thing also in the same I feel it would be nice to have as a dev developer a kind of fast track because we're going to develop our permissions for example I'm also involved in an obscene project and I found a kind of going to have to synchronization or to have to synchronization software so it would be great if we could have a kind of fast track as a dev developer but it's pretty recent it's a you have to go to the project of a permission so I just rapidly switching past to the the principle to develop the you do have to go through the thing but for dev developers we make it much more lightweight and all of this is the the different things you're capable of so yes you do have to go through that procedure but it is a fast track in the sense that you don't have to put nearly so much work into it about out of time I just want to leave you with one thought I came into this talk trying to get this discussion that we've been having going and I said I'm not a technical person but I think I've smart enough to know what and link people together so if you're a if you're a DD and you've ever find yourself that you need to talk to someone or you need to find someone in the project feel free to spam me as much as you want my job is to ensure that linkages happen between people even if I don't understand the technical aspects I can get you talking to the real people the minor people might be today or yesterday I think LWN had an article by Rafael Hergel about comparing the membership of that link and it's just a great people here might be just and if you're interested in talking more about the derivatives discussion you're running about when it's not on the schedule but we'll do our best to get it on okay thank you very much for your time