 Good morning everybody. I do not need to introduce Stefano Sacchioli. He will talk about the X and I'm enjoying this talk Thanks So this is supposed to be above but before going to both I would like to review with you briefly The initiatives we have made in we have created we have initiated in the past one year and a year and a half on the Debian derivatives mailing list to collaborate with the derivatives. So I go very quick quickly quickly to them and then I have some Question for discussion that you can find on gobby. So they are already there So if you are if you have gobby zero five You can go to you can connect to gobby Debian net and then open the DC 11 dash derivatives document So I will put it on screen when I finish and go into the slide So very quickly just first of all a bit of rationale So why I think we should collaborate with derivatives Well, I think that derivatives have changed the way in we create this toe So nowadays there are less and less distribution which are created from scratch and more and more distributions Which are created based on an existing distribution and that is great because the the derivative So the new distro created can focus on customization and the the mother distro the upstream distribution can reach out to a new public And this is both of users who benefit from the work which is done in the upstream distribution But also of potential contributors which can in theory contribute to all the tree of upstream derivatives So Debian is a particularly popular base for derivatives So if you look at these two review sites You will find out that they claim that there is something like 130 active distributions, which are based on Debian I think it's the most derived distribution which exists and I think it is the case for various reason Well and essentially the reasons are that the derivative benefit from all the quality and licensing check We do in Debian they benefit from a huge code base of packages We have something like 30,000 packages in Debian and we have a reputation to be a stable system So that's sort of shield the derivatives from unexpected packages And also we have a philosophy of not being targeted for a specific target user So if you are a derivative who want to target as the system to a specific target Well starting from someone which is supposed to be neutral is actually a good choice So I bothered you with this diagram already in my DPI talk So I won't I will skip it essentially what I'm saying is that The way we distribute software to final users has changed a lot in the past five to ten years We now have several layers several vendors which base their work one on another We have upstream software here on the left We have a first distribution who package their work and as its own users And then we have a downstream of additional derivatives that are bates one on another and at each block in that chain You get new user and potentially use contribute new contributors This is great because every time we add a block Potentially we get new users and your contributors We get free software to more people and we get free software to more eyes Which are able to spot bugs and potentially fix them. So this is great But what I've been telling to the Contributors of several Debian derivatives in the past year here and a half is that I think that we should all make an effort to make all This sustainable Because we should take care that we do not Distribute too much the work we consolidate the work so that we all benefit from the work wherever it is done in that chain So I think the the rational which I've been proposing to people that of course not everybody agrees with But I think that the vision that Debian should propose is that we are all doing a distribution Because we want to improve free software and we want free software to succeed So I'm trying to pass the message that we care more about free software itself Then about the success of a single distribution in that chain So if we if we agree on that vision I think that is the the main reason that it's pretty evident that in that case We should all make an effort that no matter where we put improvement in that chain We should make them flow upstream flow to the left So this for me is the main principle for which we should Collaborate with derivatives and that applies as Debian as it applies to other so if that principle is Worth for other then it's worth also for Debian and it means that we which are often here in this diagram Should really make an effort to push our changes upstream So this is from a universal principle which explains why we should work together with derivatives But also why we should work with our upstream which usually are the original software developers So this is pretty much it for the reason I think we should collaborate with derivatives and then I will go briefly through some of the initiatives Which have we have been create we have created in Debian in the past one year and a half to actually improve collaboration with derivatives So the first one is what we have called the derivatives from desk It started out of a discussion among several Debian and Ubuntu developers at UDSM in May 2010 and the idea of the derivatives from desk, which is something which exists in Debian is Two main purposes the first one is offering a contact point So imagine you are someone working in a derivative and you want to give back your changes to Debian But you don't know how to do that. Maybe because you don't know the How Debian is split in team maybe because you tried but you get someone did not apply to you or anything like this So the idea is to provide a contact point a mail address you can mail saying, okay I'm working on a derivative I have this bunch of changes and I want to give them give them back to Debian How could I do that? Can you help me? So this is the first all a contact point the second role of the derivatives from desk is to actually give a discussion place Where people from derivatives of from Debian can stay together and discuss on how to do collaboration with derivatives and a sort of third reason which is an Intended side effect is that to make emerge in Debian a group of people who care about Collaboration with derivatives and actually are willing to help derivatives in get the code back to that and This is what the idea The the three properties have been you can find them decline in the Well, there is a wiki page. We describe what the derivatives from desk is we have announced it in we are the Debian press There is a mailing list which is Debian derivatives at least Debian org And there is a contact point which is the contact point for external derivatives Which are not necessarily on the list and which is derivatives at Debian org which gets redirected to the mailing list So this is the idea of the derivatives from desk and I think it's been working pretty well So these are some statistics from the from the mailing list. So we are now at something like 180 members of the my reading right? Yes 180 members of the mailing list and it's fairly active So we discussed their values initiative often Every now and then we have a new derivatives popping up saying okay. This is what I'm doing. This is what we do and for every single Presentation introduction mail you get other people suggesting. Okay. This is some easy This is who you can contact in Debian to integrate your work. So I think it's working pretty well This is the first step. So the derivatives from desk a Second step, which is quite recent is what we've called decks for Debian derivatives exchange So the observation which is under which underlies decks is that We seem all to agree that patches should flow upstream We agree that in Debian patches should go and go to upstream and people in derivatives seem to agree that patches should go to Debian But actually that does not often happen often. It does not happen. So why is this the case? So if you look from the side of upstream distribution like Debian You see stuff like I can keep track of patches in so many derivatives. There are just too many So imagine this is a hypothetical maintainer and this is some of the common thought you can find Or you we have maintainer who complains the change you should be made in Debian in the first place Or you have maintainer saying you did it wrong. You did that change. That was not the way I wanted I intended it you should do that in another way and Some of the common thought we you have if you're an upstream you might have if you're an upstream Maintaining an upstream disto is that after all it's not your responsibility You have already enough to start to do and after all you are a volunteer So it's up to the downstream derivative to come to you and do the job of integrating Then if you looked from the point of view of a downstream derivative Well, you have experiences like I tried contacting the maintainer, but they never applied I gave back the patches and they've been lying they've been staying in the BTS for six months without an answer or Well, you know, we have our own problem to solve We cannot solve Debian problem and you see that the basic thoughts are the same if you look from downstream point of view It's not my responsibility. I have enough problems already and you know what I have no time I am a volunteer as well. And so who cares about the upstream distribution. So these are the two different points of view and In fact, I think we need to realize that it's not only Debian problem It's not only downstream problem, but it's actually a common problem So the idea behind that dex was to try doing something different a Bit of history all the idea of dex came out for a discussion among Myself Matt Zimmerman and other Ubuntu people last year at Epcom 10 And it was announced after some discussion on how to do that in March 2011 and the idea is to Create small initiative in which every initiative focus on a given set of patches So, you know that there is this some patches in a specific downstream distribution a specific derivative And you define you clearly define that set of those set of packages and you say, okay I want to merge that in Debian and to do that you have people working together from Debian and from the specific derivative Which is involved it is to have a relatively short projects short live which can be completed For instance in a sprint or maybe in a short time frame like a couple of months and in particular We think that having visible progress So a list of what has been done and a list of what still need to be done is Somehow useful to actually drive initiative to completion So Dex is a generic idea and you might have specific sub team and in particular right now We have only one sub team which is a team of people who cares about the integration among Debian and Ubuntu and focus on closing specific deltas in Among Debian and Ubuntu We've completed a first project within Dex which we called Ubuntu ansian patches actually they have because I didn't contribute much to this So the idea was that there was something like 250 patches in Ubuntu Which those status with respect to Debian was not clear So we didn't know if there were integrated if they were not integrated if they were obsolete with respect to Debian So essentially was a massive review process of these 250 patches which took something like two months I think it's now essentially completed and while going through that we We encountered some well expected issues for instance We encountered maintainers in Debian to which we forwarded the patches and they did not reply So or maybe they say okay We look at the tomorrow and then they don't do that pretty common beer So the idea was okay just use what we know how to use in Debian So NMU delayed NMU 15 days and we integrated a couple of patches this way and we encountered also other cases Which is like Okay, I look at your patch. I want to integrate it But I don't want to do that unless the upstream author in this sense the real sort of developer agrees with that And this is the case in which we have a different judgment call essentially some derivative It's okay. We shipping a patch and some other derivative upstream to that is not okay And this is fair. I mean we should accept the fact that we might have disagreement So the the red part which is still to do is essentially Couple of those cases. So I think it's been pretty a success and an example of how we can do thing And then we have also some resources to drive Dex initiatives we have a GSOC project and Google some of code project by not a handler Mentored by Matt Demerman and essentially is a small Task-oriented interface to see the progress. So you have a I don't have a screenshot because yesterday It was not working given that it's be we are being working on that for the doing the sum of code Which is ongoing right now, but essentially it's a list of things to be done associated to a specific initiative Possibly linked with the Debian BTS the bugs so we can see what are the bug in Debian keeping track of it but enabling you to add additional comments so you can add the comments which are not part of the the BTS like tags or Dex specific comments and It's being in use By for doing the Python 2.7 by default migration, right? Is it correct? Okay, right now and I think it's it's pretty interesting tool and potentially can become a generic tool we use in Debian to actually Do task-oriented initiatives in Debian? So it's not particularly tied to Dex. It can be made way more general than that And finally the third initiative I'd like to mention explicitly is the derivative sensors by Paul Weiss pubs And the idea was to actually have a sensors of the derivatives which exist with some more information than what we have in on this or watch so collecting from specific information about derivatives and In a way that is useful to Debian that in a way that it helps You know developing a relationship among Debian and derivatives and also which enable us to do some sort of quality assurance check Not only on Debian, but on all the derivatives we that participate in the sensors so the sensors is on this page on the wiki and At the moment we are collecting quite some information. So we are collecting for interest web contact points. So a website planet Email contacts or the like we are collecting developer oriented information like version control system Development list pointers to develop a documentation popcorn information and so on and so forth We are collecting sources list line for each distribution, which is in the census There are a couple of clever tricks to ensure that the information is current So for each enter in the census we have the maintainer of the census So who is responsible for keeping the information up to date and we have a timestamp to see how if it's possible out Today the information is possibly out of date or not and you can see the template here Well, I won't change desktop otherwise Only get issues with the beamer, but there is the census templates on the wiki and right now There are 38 derivatives indexed and I think the last one has been added today, right? So it's still pretty active and I think it's a good share of the Existed derivatives in that we have in the sense of and as interesting outcome of collecting the information Well pub cell setting up planet derivatives So we have created a planet which aggregates blog posts coming from the various derivatives We have discovered a couple of fun facts about the derivative logos like that A lot of them are created using non-free software including the Debian one We have seen some logo inheritance So if you look at the tree of derivatives you see that the sub the derivative distribution Often inherit the logo of their absolute distribution So this is fun stuff, but it is the stuff with the kind of stuff you can do when you add information and then some other Useful info that came out of the sensors. It's like we discovered that several derivatives do not ship source packages So I don't think it's out of malice, but simply they probably think it's okay because Debian has the sources But as you know license-wise is not always the case. So this is something we can improve And we for instance we provided some requirement analysis for the LinkedIn developers in how we can best support Distribution-specific checks to having by having different profiles and I'm sure pubs We can tell you more later on if you have more information about the sensors So this is the main initiative you've been going through in the past here in a year and a half And then there are some more coming. So there is a page with derivative guidelines so the idea is To leverage the experience of existing derivative and to explain to new derivatives What should they do if they want to create a Debian derivative? So what are the best practices? What should what should you change for instance to avoid that? Popcorn information goes to someone else to avoid bothering Manteners for bugs exist only in there So all this kind of knowledge which is useful to consolidate in some place and we have been doing that on the derivatives guidelines page There are plans to do integration in the sense of doing sort of Data warehousing in Debian to gather information about all the derivatives So for instance pub has been designing that gather information in UDD in packages Debian org in the PTS in the pass tracker so that it's possible to see from a central place all those information from the derivatives There are idea to integrate that in DD in the DPO and in our medicine as we already do for Ubuntu You know at least for our medicine to integrate it bug tracking system so that we can easily have links from bugs in different distribution which are related and another idea is to actually think about how we can Make debcoff a contact place which is a contact place for all derivatives And maybe even leverage some sponsoring for the rest which are interested in helping out Debian and debcoff All this is pubs powered once more so we might want to ask him for more information So this is it for a brief review of what we have been doing in the past here here in the half our own derivatives and I can leave it here for a discussion and I have a couple of topics. I'd like to discuss with you So one is the sort of philosophical So what do you think it is their role of Debian with respect to derivatives? Should we care? Should we not care and in particular? Should we expect something from the derivative or should they expect something from us? So with all the quotes you can imagine What can we do more to collaborate with derivatives or should we do less and then of course all your Experiences of collaboration with derivatives were they good were they not what can we learn from them in answering that? Please keep in mind that having had a single bad experience Doesn't mean that all the collaboration with that derivative should be bad I'm sure we have all had bad experiences in dealing with Manteners in Debian that doesn't mean that dealing in general with all Debian maintainers is something bad Okay, so please make an effort not to generalize too much and then something we really need is For decks so we often say okay We need to merge changes from derivatives, but when we sit down and look for examples It's not that easy to actually find set of patches which should be merged in Debian So if you have a specific set of patches from derivatives that you want to see merged in Debian Well, we need to learn from you because we want to set up specific initiative on that But finding that the target is not always that easy And finally about the data warehousing idea So imagine we can collect all the information about derivatives in a single central place be it UDT or any other Debian Information place well, how can we leverage this information? What can we do with that to improve quality in Debian in all derivatives? so this is This is it for the introduction and I now leave the word for leave the microphone to you for comments or whatever else Yes in the meantime and The rest can look for people with comments about all this Okay, I'm the deal, but I have two questions from RC one the first is from Kevin If Debian derive distribution scare about the packages they get from us That seems like some concern about our actions and thus maybe they want to have their voice included included in our voting That's what they what maybe they want their voice to be included in our voting That was the first question and the second one from Stuart Prescott Question there looks like there's a very low bus factor in this work Well, pups is the bus factor. So how does tax moves beyond baps power? Well, I leave that to pubs actually so the code that I've written for doing some checks on the census information is available on the alias so anyone can check it out and And work on it and if you care about integration of derivatives into Debian I would definitely welcome your participation in the census stuff Up till now Mostly haven't been pushing my Emails on to the Debian wiki, but I'm working on Doing that so that other people can also do checks on the census information and send out pre-prepared Templates, I mean pre-prepared emails about issues that I have found so far I think it's on the census QA page what I've done so far. I've got to add more emails later But yeah, if anyone wants to help out that'd be awesome Yeah, and regarding the deck specific initiative there the kudos goes mostly to Matt Zimmerman, which has been doing most of the initial design of the idea and also You know driven the the first initiatives we completed anyone else experience to share Suggestion on how to improve collaboration. I have also a question because in the beginning you said Debian is quite neutral this is correct, but Well in the next talk I try to say that we have internal Customization or preparation for derivatives, which could also be helpful and could be enhanced. Yes I mean that's so in general. I think the relationship among blends and derivatives is a very interesting topic. So What do you think have you ever thought about, you know promoting specific derivatives as Debian blends have this ever happened? Yeah I'm not sure. I'm I think the concept of blends is Not back up by so many very good examples So we cannot really tell I would love if there would be even more specific plans and if more examples because Finally either you can this blend just now on your computer if it fits or you can make a very very easy Derivative because everything is single there to you can put your brand on it or some customization Which are for whatever reason not possible in Debian, but in my opinion It makes perfectly sense to to prepare what you want to do inside Debian because it's just less work they don't Okay, I do and Debian person, but this is a more general query right from the from the work you've done on censoring derivatives. Have you worked out? common mechanisms for how people manage their Difference essentially and is there more we should be doing? Within Debian to allow those differences to be pushed upstream You know there's all sorts of mechanism you can imagine and I wonder a what everybody does at the moment and be whether they would As Andrea says whether we should be doing more of that in Debian There's quite a lot of if a bun to if Debian in various packages now So, you know they've managed to shove that upstream But then there's another hundred distros which probably have similar things and we don't really want a hundred if this if that if the other Just in case people don't know about it because it was introduced a year or two ago. There's The Deepakage vendor command these days supports saying whether you're derived from Distribution that's thanks to Raphael Hertz. I believe so if you're So if the intent is to say that anything it anything that is say Ubuntu or best on Ubuntu should behave the same way Then then you can get that swith of derivatives in one go Maybe you should explain a little bit. How does it work? I'm not sure if everyone is familiar with the pkg vendor sure I think it might be best just to refer people to the man page. It's but essentially is a Deepakage tool which can use in white when you build your package to take Different action based in based on which derivative is the packages your package is being built on so you can ever see But that doesn't try to solve your Issue with if this even that but it enables to actually have all the code in the source package Which is as much as stream as possible It allows you to consider sort of the branching structure of derivatives in a slightly more sensible way I will say I'm not sure how many Debian derivatives other than Ubuntu set it up correctly I simply don't know but it at least provides the potential for people to do that Yeah, I mean that's that's exactly the sort of mechanism I met and that's mechanism We've provided to allow those changes to go upstream and the question is how many derivatives does that satisfy? You know and she'll be doing more of that or are in fact different sorts of mechanisms because things don't really fit in The packages in the same way and that's you know, not quite what's needed And I guess you now have a better overview of that than most people And to be honest, I haven't really looked into the The kind of differences that the derivatives make quite yet Probably will start doing that once I have the packages info and UDD and other things And when I start looking at integration of that with the patch tracker divin.org there is some information and about this stuff like D branding Debian in the Derivatives guidelines wiki page Do you know if it mentions the pkg vendor? I don't remember that. I'm not sure But I think in Debian we could we could Be doing a lot more Work on splitting out Debian branding into specific packages instead of being embedded in this in the package Instead so that would mean that we could have a Debian branding package and Ubuntu wouldn't need to ship that or whatever distro wouldn't need to ship that that ship their own branding I Think we could do with quite a bit of work on that as a lot of source packages that have Debian logos or whatever that and then that could be in separate packages like desktop place there are also a very large number of Translatable strings that mentioned specifically Debian I've changed number who's in the past. I knew others have generally trying to make them more generic and less Debian specific It's not always appropriate if you're if you're looking at the string that says Debian installer men menu It's not really appropriate to make that more generic. So and unfortunately, it's rather difficult to Make it to simply substitute in the name because an awful lot of languages Transliterate the name of the distribution and decline it according to their grammatical rules That turns into a bit of a nightmare Well as to the question of wookie whether other distributions were using this whether it's useful. It's immensely useful For the past releases we also completely relied on LSB info. So we had to patch a lot of I think we dropped at least 2,000 patches Simply by switching to a DPK vendor because now we just declare that Debian is our parent is true And so we can just throw away. I think at least 2,000 packages on the other side I only stumbled upon DPK g-vendor by accident when I was patching a completely different package And I notice what's that? Oh, this is cool. We can drop a lot of other stuff. So Well, maybe it was it was just me missing it, but It could possibly use a bit more publicity or or some some guidelines how to do it, right? Just very quick reply. So this kind of gotcha was actually the reason to create the guidelines in the first place It's very new documentation. So I'm not surprised it misses this kind of stuff But maybe if you still have fresh memories of your, you know, bad experiences Oh, I should have known that and they didn't maybe you can check the page and see what is missing Yeah, I would like to chime in exactly on that It'd be great to encourage derivatives to publish their best practice publish how they How they derive from Debian? I have been building countless derivatives for little tiny ones and we have recipes for unattended installation and live CD builds Building from a clean subversion repository with a Debian mirror with no craft on it and all sort of things We've never managed to push them up straight to to make people aware of them I sometimes block them on my blog, but there should be something a bit better and well at the end of the job, we probably Forget to do it because there's a new job coming in so even for decks to be proactive and kind of reach out to people and say, oh you've done that how and And that can become a point of discussion like people can say well, I've done it in the other way That's much more convenient. Oh, yeah, cool. And and eventually you end up with recipes and that practices unfortunately recipes change each new Debian stable because Debian installer gets refactored and so often some of them have to be thrown away Unfortunately, but what can we do with that? But still at least and if Debian knows about these what people are Doing to derive it. Maybe Debian can support it better I reckon if the Debian installer people knew what are the most common recipes people are using they may try to kind of provide a stable API about it Paul you wanted to add something I would I'd like to comment on this Because if you get the drivers to write down how and why they did it In my opinion, not in the main and the main basic there what is but and several small ones They are just doing because you can do it It is a common reason just because it's possible and I think perhaps some some a little bit more Communication that it's possible, but not always the most effective way would get rid of 25% I apologize. I missed Quoting your documentation work you do in Debian blend This is what I mean because It's good to have a derivative. It's quite but but some just create extra work for one or two people So you're making the point of the ego derivative, right? I Already wrote a few notes on the copy document one of them is an enhancement. Maybe of what Eric was saying is We key dot ubuntu.com as a really good good page, which is the Ubuntu for Debian developers Which is really useful for someone that doesn't want that already knows many of the Procedures that can happen in a Debian based distribution and it does only want to know the modification the the diff between Debian and the and the Ubuntu and the derivative distribution workflow and Maybe it would be it would be useful with other distribution at the such documentation as well And also, maybe we should generalize it and Maybe we should generalize it and make a sort of as neutral document as possible. I don't know Sorry And the other thing is that I'd like to see in in our Okay services QA services and so on like pts bts and so on Information about what's going on in in derivatives So I think that it would be useful if derivatives would publish and machine readable List of anything that can be helpful for us to know about them And our services integrate this maybe in other pages if there is too much information to stay in just one page Okay, this can be discussed But anyway, this would be really helpful not to have anything to check 1,000 pages to know Something that is exactly what Paul is working on with the integration stuff. I Thank him for that So on the machine readable part of your question or your comment I chose To do it with the wiki because I think it reduces the barrier to entry of If you if we require people to write some specific machine readable format read documentation and stuff It I think it's too much of a barrier to entry for these people It's a lot easier for them to register on the wiki and edit a template than it is to Do that sort of thing and so the scripts that I've written a flexible enough to read that template and Work with it Yeah, you're doing now some automatic processing based on the templates right correct. Yeah We have some more questions from RC As far as I know the person asking the question is a sedux after seed developer What are the Experiences good or bad between Debian and derivatives Ubuntu and Debian seems to work nicely according to a mediator Does the co-working means mainly to get patches from one to the other distribution? And how can a user get more aware of this text exchange other than reading package change locks? That's a nice question. So I we Do so we do encourage derivatives to for instance Add specific tags user tags to the bts so that we can have for instance a list of Bugs which have been forwarded from derivatives up to Debian and then of course to see what has been you know done I integrate and what has been not but as far as I remember very few derivatives actually do that Ubuntu does that some other are doing that So I think this is part of the you know the stuff we are trying to push forward because Essentially in Debian to be honest. We didn't work much with derivatives before Having discussed that deeply with the Ubuntu people and now we really need to generalize a bit all the stuff We have learned in the relationship with Ubuntu and try to encourage all other derivatives in doing that But up to now we have not been really been you have not been very successful I think in you know promoting good practices to other derivatives Well, I have a question What do people think about our bts being the right tool for this because it's well known that the email is not Necessarily a good tool for everyone. So do people think we need another tool or is it sufficient to force people to use ours? I leave that to the pitchfork of the public For the last question a filipon Unvention we are currently in a transition from Lenny to squeeze and Regarding the decks work. We think we all When we do the switch over we will review all our patches and then go the decks way and send our patches Which are still relevant upstream to Debian? That's great So sorry about your question. Just just a comment. So I think in general in free software We need bridges among bug tracking systems no matter what are they where or communicating one to another So I don't think the real problem is just email because in another system The problem can be that you only fix bugs by committing to a bug a gate branch So I mean there is some sort of impedance mismatch among back talking system And that is I think a more general issue that need to be taken In regards to whether the bts is the right tool for this I feel that as long as Debian has such an email driven culture It makes sense to encourage email tools so that others who want to be involved either Then just be able to continue the conversation when it goes out of the bts or into another Debian for Barre yeah, my name is peter anilson and Two observations first you seem to be arguing that all Patches in derivatives should be sent to Debian But isn't it true that most of them should be sent directly to upstream and not bother Well the intermediates at all and just get it straight into the upstream and Get it to Debian from upstream The other thing I've seen is in my work with the system v in it the packet is it's very useful to check out the The non-debian derivatives as well. I've been patching patches from Red Hat from SUSE from Gento to improve the Debian packages and also to Send them to upstream to make sure that the new version is so used all over the place So we should also for to remember the non-debian Distributions and check out their changes because there is quite a lot of nice changes done there, too Okay, so let me clarify that I think that Everyone in that change should push thing upstream so that's a general principle which holds for us as well So if we receive a change for derivatives, I think it's our duty to push it upstream But in fact the question is how do you want to push it upstream? Do you want to do imagine there you have a chain which is five blocks? Do you want to do all the way block by block or you want to push it directly upstream? And this is a discussion we have had on the Debian derivative is made in this together with the Jorge Castro from from Ubuntu and I think in the wiki page It is me mentioned before there are there is a nice classification of the cases in which you want to push a thing to your Upstream distribution and the cases in which you want to push the change directly to the actual software developer And of course in general it is if it is a packaging change You want to push to your derivative upstream if it is a purely software change You want to push it to the upstream software author But even in this case it get complex because maybe you push a change a software change to the upstream software author But that upstream is not active anymore. It's not reactive So if you do only that it may you know stay there forever and other derivatives do not benefit from it So I think we should agree on the general principle and then there will be cases in which you need to make exceptions In order to have more users possible benefit from the change We have five minutes left. Yeah, just a quick comment on that is We did the back dbn backtracking system is fully opened So we can actually ask our downstreams to report bugs to the dbn BTS and then to forward that to upstream They're like totally autonomous to do so and should yeah, I know what the end is going to say No, no go ahead go ahead Thank you. Well, I don't think there's a one Oh One-size-fits-all answer to these questions in general, you know, if you're a user even and you're submitting a bug where you submit that bug depends so much on How much you know about the program and how much you know about upstream and where? Where is the most efficient and effective place to file that bug and often as a user or a downstream? It will be easier to file the bug to debbing because that gives you a consistent and clear interface on the other hand If you're getting deeply involved with the upstream code You're probably going to have to get familiar with the upstream project anyway And then you will know whether upstream is active whether you need to send the bug to upstream What the right thing to do is and I don't think there's a hard and fast rule You should just do the thing that is in the particular situation the most convenient for everybody very cool wanted to talk about the representation of derivatives in dbn Are existing derivatives all Having one DD among them that knows what happens in Debian and can vote in Debian or if not is That that could be something we could encourage I know that the grandma people applied to DNM process here the comf and I thank them for it And I promise I'll look into it as soon as I have a shred of time but and I will think that could be encouraged because they are doing, you know, technical work in Debian and I know maybe it's yeah, that's quite an interesting discussion, but I think we have never actually had that I think it would be an interesting thing to actually encourage. Yes Okay, so we have one minute left. So it's about time. Go ahead, but just one comment about the suggestion before about their collaboration with non Debian derivatives and non Debian base distros One tool that I find really useful is a program called who has You run who has your package name and then you get a list of links to other distros and Where you can find information about that package in those distros often I found patches and bugs that need to be fixed and and Commented on say a gentoo bug saying that, you know, this is the patch you need to apply for that Yeah, that's a really useful tool. I'm not sure if there are any others, but I'd be interested to hear about Things we could do about making that easier So just one small request given time is up if you have your Pet set of patches in some derivative that you really want to see it in Debian Please show up on the Debian derivative is made in list and mention that because it's very easy to say Oh, you know those distribution are not giving back to Debian But then when it comes down to identifying a set of changes and working together with them to merge it Well in our experience with dexos those far is not that easy to actually identify the targets So your input on that is very welcome Thanks a lot