 Thanks. So as people walked in there, I'm Benjamin Macohill, and my role today is going to be to facilitate the session, which means I'm going to try to talk as little as possible. As a way of introduction, I've been involved in two derivatives, really. I've been involved in a reasonably short-lived derivative called Debian Nonprofit, which put out a release and a release and a half or so, which was a version of Debian geared for non-profit organizations that was done within the Debian project, wherever possible. But you want to grab a chair if you want to? You should. OK. All right. And then I've been involved in the Ubuntu project, which I helped. I was one of the people who sort of was around for the beginning of that as well. And I'm still involved in Ubuntu, although no longer work for Canonical. As you walked in, I had a very old list of 129 different Debian-based distributions as listed on DistroWatch. And I think as of today, there's closer to 200 of them. And that's not counting something that didn't exist at the time that I originally took that list, which is the derivatives of Debian. Ubuntu has, I don't know, a dozen or so derivative distributions in a series of other Debian derivatives have derivatives as well. So one thing that I've thought for a long time is that Debian sort of going through this place where it's no longer pursuing the goal of being the universal operating system in a different way. At some point in the near future, I don't know if it's happened or if it will happen. I think that most Debian users will not be using Debian directly. But they'll be using Debian indirectly. And Debian exists as a very important node in an ecosystem of different distributions and drivers as the central node. Debian is, as I said yesterday in a different talk, perhaps the largest voluntary free software project, and in many senses the most expansive free software project and distribution in existence. So it places this important role. Everyone up here represents a derivative of Debian. And what I want to see come out of this session is a series of things. I want a little bit of conversation where we can sort of help us, Debian, understand why there are so many derivatives and the fact that, as it turns out, one size does not fit all in many cases. And then to sort of come to terms with this in ways that can lead to sort of more understanding and more productive relationships, I want us to ask ourselves what it means to be in the ecosystem of distributions. And I want to put derivatives both in touch with each other and to sort of explain some of the common problems that we have so that Debian, as an organization, can find ways of working with derivatives and ways that benefits Debian and that ultimately benefits derivatives as well. I think that one thing that we all have in common, the reason, you know, every derivative that base themselves off Debian do it because Debian offers a great place of divergence and a way to do less work for the derivative. And I think that done well, derivation will be something that can save everyone a lot of time, including people that use vanilla Debian. So I'm also interested in sort of helping create more of an open venue where we can document these processes and put people in touch and start thinking about what to do with tricky issues. So I sent out a couple calls to a various lists where I asked for people from derivatives to sort of, you know, who we're going to be here to state what they were interested in getting at. And I asked a series of questions and I asked people to spend roughly about five minutes sort of quickly introducing their derivative. I asked people to give a brief description of their project and the nature of the relationship to Debian. And to answer the question, why didn't you just use Debian? Or in other words, in what ways if you diverge or in what ways did you need to diverge? And then maybe if, and then, you know, at their option, a description of their greatest frustrations in working with the Debian project. And maybe, you know, things that have been very great or useful, things you want to see more of, and maybe even a description of a mistake made or a lesson learned. So, you know, with that introduction, I'd like to turn it over to each of the derivatives and to allow them to sort of do a quick thing. And then I want to turn it directly over to questions both from the floor and from, you know, derivative to derivative insofar as that's useful as well. So without further ado, let's get started. Do you want to, I don't know, do you want to go first or no? Hi, yeah. My name's Luke, Luke Layton. I've done two derivatives of Debian, which basically made modifications, installed a series of defaults which achieved specific goals. The first one was Debian says, secure easy, I'm sorry for the Americanism, for those people who are European. The purpose of that was to basically set up a secure, easily installable system. And to that end, it had to do security-enhanced Linux, not the targeted policy, but the strict policy. And it also had to run a desktop. Now, I don't know if anybody's tried the security-enhanced Linux, but Debian was definitely not ready for coping with SE Linux at all for various reasons. And it also didn't help that I would just started this at the time when the freeze had taken it, it was in place. So that was what, three years ago? The Sarge etch freeze? Yeah, I was thinking, so even some of the modifications that were required were to base packages, essential packages, which I think, so libSE Linux couldn't even be included. I think there were some dependencies going on as a modification squared. So that process got in the way. Then I needed a different type of a set of KDE defaults. I needed supercaram, put supercaramber over a bar, and I put on kicker menu at the top. So it looked very similar to GNOME with the kicker menu. It was just basic things like the usability of the system. I actually thought about the usability. I designed an OSX bar, which had hierarchical menus so that you didn't have to go, the users who did not. I mean, I gave the example of my uncle, who's had a tendon removed from his arm. Plus, he's dyslexic, and he wears glasses. So he uses the mouse like this, there. Right, OK, let's move it on to the right place. Now I need to press the button and puts his finger on the button and moves the mouse at the same time, because he's just not used to that level of coordination. Now, if you put somebody on the K menu and they have to go click up sideways, up sideways, now, so that putting a menu at the top way just go click down was much better. Little things like that made it so much easier. But that's not even, I found this menu system, kicker menu system, I put a request for packaging three years ago, and it still hasn't been put in. It still hasn't been included after three years in Debian. So that's some idea of how long it takes to get stuff, we get things in. They just got completely missed. That was even after reporting it using ReportBug. That was the first one I did. So there was nothing about Security Hands Linux. I was just pioneering pretty much everything. So I couldn't do it. So the second one I did was very similar, which is an unattended install. An unattended install system where everything was done. So based on the Debian install of the work that Phil Hands did, it pre-answered all of the questions. So a different version of what I did before. But again, using Wget to fetch packages that didn't exist in many things, making modifications to config files, for example, changing fsckfix equals yes, rather than fsckfix equals no, which again, I've raised a bug about it, but it still hasn't been actioned and nothing's been added to the Debian configuration options to make the change, which would make a simple thing, which means that when an ordinary user's computer crashes and the hard drive gets corrupted, they don't get presented with this thing which says press control D to continue so they continue and then phoned me up and complained six months later when the system doesn't work because it's totally corrupted the hard drive. Because every day they're on the switch machine on, they further corrupted the hard drive. It's little things like that. They just don't get into the distributions. Okay, so I'm Josep Arela. I'm from Venezuela. I'm here representing the Venezuelan government, which has a national distribution. We exist because there's a lot of misunderstanding in the country about what to use and how to use free software in the public administration. We have a legal requirement of all offices in the government to use free software. And sometimes when you say to people who has gone to conferences outside the country, you tell them to use Debian and they say, well, outside everybody talks about Red Hat or Suze or any other commercial distribution. And taking into account this, the government decided to make its own distribution, which is Debian-based. And until now we have only diverged a little bit from Debian because we're using mainly preceding and we are just modifying desktop-based and we don't have proper repositories. We haven't forked the whole package base of Debian yet, as for example, Ubuntu has done. So this is a very mild way of introducing Debian into the government without saying that it's Debian. It's mainly because it's not invented here, problem that affects a lot of IT solutions in the world. We didn't just use Debian because of that because people will say, well, it's Debian, it's just made by a bunch of hippies and everything. Because people will reject that we're just making our own distribution. Until now we have used Debian Live from our own live cities and we are just using the Debian installer with preceding options. I have made another distribution for a company which needed to go further beyond preceding because for example, the PAM underscore LDAP packages did not make the possibility of preceding almost every option. In general, we think that we should be contributing more to Debian in the way of patches and modified package and ideas, but we find for example, the book tracking system a little bit tough to be used by people who has no previous contributions to Debian. That's why we have like 13 or 14 maintainers in our country which are trying to improve the way things are happening and we have a little project to make a web-based tool set for developers which includes a building daemon, web-based and a book reporter which will also be web-based in a sort of launchpad thing but not exact project. And a mistake we have made was this one just not turning back our contributions to the Debian project because we think that Debian could, for example, maintainers could take our change and add them to the package and then we just don't maintain them anymore and that's a good thing. But mainly the problem was the book tracking system and the way people should be involved in Debian in order to make a contribution. Sometimes you set something in a mailing list and you get flame or anything or you just are not being taken into account. So this way we're trying to make our change in a lower level and then maybe Debian Venezuela or any other group of developers can take that, compress that and resume that and send to Debian in a good way. That's basically what we have done in Venezuela and it's not a derived project. We have just diverged a little bit and we're mainly using Debian. And if somebody wants to use Debian it's supported by the government so there's no problem there. All right. Hello, my name is Cesar and I'm one of the GNULI Next developers. I work for the regional government of Extremadura in Spain and as most of you probably know we are using a Debian-based distribution. We assist because the government decided to use computers in the schools and also in the public administration. So we decided to go free software because we think at the beginning that it would be better for us to base distribution in free distribution not supported by any company of the United States or South America or South Africa. And that's the reason we chose Debian to base our work. We are now using SART as a base but we have been packaging some kernels and also a new version of GNOME because we need to support a huge variety of hardware. And we also chose Debian because we think that it is very stable not like other distributions. And also because of course it is free and free like as in beer so we don't need to pay to any company to develop our software. Some of our biggest frustrations in working with Debian was the lack of a graphical installer. That's the reason we are still using Anaconda. This thing will be changed in the future. We are moving to the graphical installer because we think that it would be better for us to base all the distribution in a Debian package or Debian repositories without the need of having an external installer like Anaconda. And one of the things that may be improved in Debian to help us is sometimes that some of the packages have a lot of bugs that are not feast in short time and sometimes we have the time to send some patches to the repositories but we are quite busy to send a lot of patches. So maybe because all the developers are quite busy and they don't have enough time to send some patches we are sometimes tied to some packages with bugs and we need to fix those bugs and sometimes it is not easy for us because we don't know how to do that. And how could Debian change to help us? We are now getting involved with the Debian Edu Scholar Linux project and we are trying to push some of our packages upstream and we hope that having all our applications and packages inside the Debian repositories will be quite good for us in the future. So we will keep on working with the Debian Edu team to be able to achieve our goals. My name is Petter Reinholtzen and I am one of the initiators of the School Linux project which was merged with the Debian Edu project created by Rafael Hartzog quite a few years ago. We started because we wanted to provide a different alternative for the pupils in the Norwegian schools than what was present at the time when we started in 2001. We wanted to be able to tell the pupils that it is not a criminal act to share and learn how the system is working. We wanted them to be able to cooperate with each other even on the software level without being prosecuted and being told to be thieves. We wanted the pupils to be able to dig into the system and learn how it's actually constructed. Those curious on how the computer is working should be able to find out by looking at the source, by looking at the configuration, by looking at the system. And we didn't want them to be presented with what I would call an engine with a shut, with a closed box around it. We wanted them to be able to find out how things are working. So the focus for our project has always been to get free software into the schools. We are not into developing software as such. We do that as required when there is no alternative already ready for us, but we are into deployment more than development. And we picked Debian by poor chance one summer in 2001. I said that, well, if we go for Debian, I can fix a CD in a month because I've heard about this DBN CD packet that was capable of producing installed CDs for DBN. And I had no idea what read that or SUSE or whatever alternatives we had, how they made CDs. Nobody else was able to top that offer. So we went with Debian. Of course, we've been very happy with that choice. We discovered more and more on how Debian allowed us to participate in the development and poke the developers to move in our direction and also to empower the users themselves to contact and work with Debian. We have provided a list of packages that is pre-configured and pre-installed in School Linux, but the rest of the Debian archive is available for all our users, and they are using some applications where we would never imagine that it was school-related at all. For example, the Scribus publishing system is used quite a lot, and we hadn't actually put it on our task list before our teacher asked us what should we do and why it's not Scribus on the DVD. Well, no, it is. We have worked quite hard to push our changes back into Debian. When we started, it was like, I think we had like 40 special packages, backpots, patched versions, modifications, and configuration packages at the moment with the edge-based version. We are down to, I think, eight, and hopefully half of them will be fixed in Lennie if I'm able to convince the maintainer to get the patches we want in there. Not quite sure where to continue. We have been cooperating with a lot of other related projects like Linux in Spain and French... It's the name of it, Emmaus Activity. We've been approached by project and people that want to use Linux in a school environment all over the world. For example, the Norwegian Fair project approached us and asked if they can use school Linux in the used computers they are shipping to Africa. So we have probably a few hundred schools in Africa running school Linux. And the Emmaus organization in France had a similar problem. They are refurbishing used stuff like furniture, clouds, and computers. And for the computers, they needed software to put on it. And they discovered school Linux DB and EDU and found that it was really suited for their need. The focus of the school Linux configuration has been to provide out-of-the-box experience for schools. It's basically a copy of the network structure from the Norwegian universities in Tromsø and Oslo. It's like a centralized file server, user directory, log server, system administration tools, and then the desktops, the workstations, connect to these and use the services. And this is working out-of-the-box. So you have an LDAP directory with all the users and you have unified logins so all the users can log into any machine and get access to their files and the services on the network. Of course, this has been quite a challenge within Debian because not all Debian packages, actually very few Debian packages, are prepared for automatic configuration at install time. And even if they are, it's normally a pain to upgrade them when the configuration files are not identical to the configuration file that was included in the package when it was installed. This has improved quite a lot with Debian preceding and general awareness in the Debian community that this is important, but we still meet developers within the Debian community that believes that an editor is the perfect configuration management tool and upgrading is something that is only left for advanced system administrators. And upgrades is a pain because normally with these problematic packages, the school is left with two options. They can keep the old configuration that used to work with the old package or get a new configuration file that doesn't contain the configuration they need. And neither of the two options is actually useful. So that is still a challenge to us to find a way to handle upgrades cleanly and automatically. Yeah, did I forget something? I think that's about it. Hi, thanks better. I'm Colin Watson, I work for Canonical on the Ubuntu project. I guess most people probably knew roughly where Ubuntu comes from, but we were founded in 2004 by Mark Shuttleworth and a bunch of other Debian developers who founded Canonical, plus some people from various other communities like the Canon project and Arch. We're there to exist, to create a mass market variant of Debian that's released very regularly on a time-based schedule and that's commercially supported, but always with Debian as the base. Miko asked how we've diverged or derived. So I guess we've made more ambitious changes than most other Debian derivatives. We've got about 2,000 modified source packages at the moment and about 9,500 on modified. That has held pretty much steady over the last couple of release cycles. So I think that's about the current figure, but of course a number of things get newly modified and a lot of changes have been passed back over that time. It's not been entirely static. The changes we make are some of them bug fixes, some of them are different integration decisions, so we have our own kernel, which is quite close to stock upstream with some extra modules that we need for one reason or another. We bought into Project Utopia very heavily early on, so we bought into Udev right at the start, HAL, going to volume manager, that stack. We've got a strong interest in Python and so on. Of the other things we include, we've got a fully installable live CD with a graphical installer that's rather complex front-end over DI. We started out looking at GTK DI and put some work into that early on. At the time, that was moving quite slowly, so we ended up and wasn't quite meeting our needs, so we ended up going a slightly different route. We've got less upfront customization than your typical Debian install does. We focused on having much fewer questions, which I guess is a consequence of having a different focus to start with. We were focusing quite strongly on desktop and laptop users and less on complicated server installs. That may change. We've remained very current in certain selected areas, which is another cause of divergence. So even if Debian is frozen for one reason or another, we still remain very current with GNOME. We keep up to date with current upstream kernel. That's led to differences in various parts of the distribution. And we've focused on allowing further derivation by removing some bits and pieces that derivatives need to deal with rebranding. Some of that's gone back to Debian as well. We didn't just use Debian because we were intending to desync from Debian's really scheduled right from the start. And to some extent, that's bound to create divergence and we knew that. We were also taking some quite ambitious goals across the distribution. And one of the things we wanted to do when setting up Ubuntu was to break the container lock on Debian packages, which makes it very difficult to perform large transitions across the whole package archive. And that's something that we didn't want to deal with as a company. We also wanted to have the flexibility, the ability to make various different decisions from Debian and ideally to persuade other people that the route we'd chosen was the right one, but if we couldn't, sometimes we knew that we were going to have to take a different decision for one reason or another. I guess our greatest frustration is that we've contributed a lot of stuff, but we are perhaps inevitably held a higher standard in some places than others have been. There are also some things we'd like to contribute back to Debian, but if you're talking about integration changes across the whole distro, there's quite a high activation energy involved in doing that, and sometimes developers end up just doing it in Ubuntu and stopping there, partly because the technical authority in Debian is the entire container body, so it can be quite difficult to get decisions taken sometimes. And yeah, I guess the biggest thing we'd like to see change in Debian as a result of that is to have a stronger technical authority that could effectively take decisions on behalf of the whole distro. If we were in that position, I think, Debian would be, that's one thing that I'm hearing from a lot of the other distributions that it's hard to get. It's hard to get certain kinds of changes made, and I think that would help everybody. Thank you. My name is Andreas Tillem. I started the Debian Meet project in the year 2001, and I went a little bit a different way because I did not choose to come from outside and went back, but just kept the power of Debian to grow inside up. It is about application of medical care in a wider sense, so we have one part, the microbiology part. There were some applications in Debian at this time when Debian Meet started, and now we have 10 times more, so this is quite successful, and microbiologists are happily using it. The other side is the patient management part. What do you expect if you go to your doctor that is running on the system of the doctor? The problem is that there is not so much upstream software which is fit for a smooth integration, and so this is the hard part of the project, and it is not so developed on our side and on the upstream side, so we are working on it. The plan is to make Debian the system of choice for medical stuff, and so make some kickstart in this field for also free software. This is more or less the sense in this part. So in principle, I answered the next question, whether in how far the Debian Meet project differs from Debian. It just does not differ because everything is inside in Debian because we are not really strong enough to go outside, and the idea is to make some separate installer later on which just contains medical stuff, but currently there is not yet any need for an extra installer because if you use plan Debian and install the meta packages, you are just ready with everything we have. So Debian is not split from Debian, and in general, I try to get these custom Debian distributions inside the Debian community, that it is quite a good idea to stay inside Debian, but my greatest frustration is that the communication in between these custom Debian distributions is quite weak. We should implement some common technologies and I tried a little bit to implement this on a technical base and I failed more or less regarding the acceptance of these tools, and I have some ideas how to make this better, and I really liked the part when you said that Linux is cooperating with JBL and edu, so there is something like, well, we share our ideas and work together and don't reinvent the wheel, and this is more or less the thing what my main focus is about in this field. Well, yes, in principle, this is what I wanted to say, so we want to share some technical stuff and keep the idea alive that we build a strong community of custom Debian distributions. Thank you. Hi everyone, my name is Kai Hendry, and I'm a South African who lives in London. So what did I do? I founded Web Converger, which is a Debian derivative last February, though I've been doing a couple of derivatives before that in Korea, Hanuk's, and I've been working on an embedded distribution, which I don't think I can talk about still, but anyway. So the derivative of it is what I like to call a web operating system. It's pretty much a web kiosk, boots up, does X, and gives you ice weasel, which is locked down. It's all based on the edge. So it's basically Debian, but missing a lot of stuff. So how are we derived? Yeah, one or two packages, and I pushed most of the stuff to the Debian live project as much as I could, so I haven't really modified any Debian packages. There's a couple of packages of my own. That's about it. It's very, very, not much. It's pretty lean and mean. So why not just use Debian? Well, I pretty much do just use Debian, but I'd like to have a separate repo, just in case I need to respond to some of my clients' sort of needs and wishes. And what is my greatest frustration? Basically not being a Debian developer. You know, I've been on the new NMQ for about four years now, and I'm in damnation as they call it. So, and the other frustration is that I really care quite deeply about the web, and I sometimes think that Debian developers, you know, the general attitude to PHP and all that stuff, they don't really think of the web as seriously as I do. As for mistakes, yeah, I made a few, gosh. And my biggest mistake probably with my latest project is not charging my customers appropriately, because my customers are seemingly banks at the moment, and it doesn't make sense to charge them a few dollars for what I do. Because basically I'm just making customized CDs with home pages and things like that. So, and how can Debian help me? Well, Debian is really, really helping me. It'd be nice to be a Debian developer one day, so it'd be easier to push things and put in my own packages if I like, because, yeah, you can turn your Debian distribution to Webkiosk, something like that. That's it, really. Okay, so I've actually taken a bunch of notes which I won't go over now, because I want to encourage people who have questions to come up and ask them. So, yeah, but I'll post them on the web afterwards, and I've sort of tried to synthesize a lot of the things that have been said here, and sort of categorize it into different types of derivations, different reasons for derivation, sort of classifications of what that is. So, yeah, check it out after the session. So, several folks mentioned things, and I think Colin articulated this perhaps the best, that there was sort of a desire for a central, authoritative, technical decision-making point in Debian. I'm not entirely sure what's being asked for there. Colin, maybe you could spend just a minute or two talking about that. Is this sort of this convergence of make a technical decision that in effect ends up being a change in policy, which you would then like to rapidly implement across lots of packages, or what's the thing that's missing that our current structure and technical committee and so forth don't make happen for you? Okay, I'll see what I can do. So, I guess if you're trying to make a change that's across a couple hundred packages, let's say. So, certain kinds of transitions are good examples, changes of defaults across a wide range of packages. You can do it, it just takes a long time. You can file bugs against every single package affected and get, and try to get every maintainer to gradually adopt your patches or not, as the case may be. See, things like the, let me see, one recent one would be adding debug packages to all Python modules, so we've got a facility centrally in the Python build system to do that, but every Python extension has to be modified slightly to spit out the right debug package. It's a fairly trivial thing to do, and in some senses doesn't justify lots of energy being spent on it, but if you want to actually make it happen consistently, you, without the ability to just upload everything across the distribution, you have to persuade every maintainer individually. And I think we'd like there to be a way to, for people who are taking responsibility for areas of work that are orthogonal to packages, that they should have the ability to do that without necessarily assuming package maintenance of every single affected package. You're correct. I ran into the problem of changing several packages in Debian quite a bit, and it is painful. For example, now I'm working on the dependency-based boot system, and that requires changes to probably, I don't know, three, 400 packages. Yeah, and he said the same goes for Upstart. And to talk to all those maintainers and convince them individually that this is a good thing, is really a lot of work, and it takes forever. A similar problem I've run into was to add the progress bar support to the normal Debian boot system. It requires changes to probably like less than 10 packages, but some of the maintainers are actively against making it easy for progress bars, and some of them are just dragging their feet and not updating packages. This takes forever, and as long as you don't have anyone making a decision and making the authority that this is going to happen, it's a very painful process to do another thing. The disconnect that I have, though, Petter, is that I think that's an excellent articulation of a problem, but I still sort of haven't heard a suggestion of what you would do differently to actually make this happen faster. It sounds like Joey wants to jump up, but this is something that's come up now, I think, in conversations at Dubcons for two, three, four, five years, so if it's one of those metatopics that we ought to... Well, my question, I don't know if Steve Langesek is in the room to... He's right behind you. Okay, Steve, what about release goals? Isn't this basically the same thing as a release goal except it's not tied to a specific release? Well, not necessarily. As I've understood the release goal mechanism, the idea is that a team says we want X to happen, and once it's accepted as a release goal, they can go make it happen, basically. That's probably wildly inaccurate, but... Yeah, as far as implementation of release goals, they're as slow or as fast as the manpower that your Devin developers have available to put into it because if it's an agreed upon release goal that the release team has endorsed, we basically say, do zero-day NMUs for it and make it happen at any point you want to. Yeah, I guess some of this has changed since I was released on Azure, so... So part of what I think I'm trying to push back on a little bit is we seem to... There's several things that have sort of changed in Devin in the last few years. Sure. And one of the things I'd like to change is it seems we are sort of building this unconscious meme that Devin is huge and bureaucratic and hard to do things with, and I think that in any single point instance, it's easy to feel that way, and yet when we're talking about things that are fundamentally useful, whether it's immediately specifically for the next stable release of Devin or for some larger use of Devin in the ecosystem, I would at least like to encourage us to be thinking in terms of these are things we can make happen, can get done and should collectively have the willpower to come up with good answers for and just get on with it. So, pardon me for pontificating for a moment, but this is one of those things that I think it's important for us to not sort of get too mired in our own self-fulfilling prophecies on. Sure, I brought it up, not because I... I brought it up not because I wanted to bitch about it, but because I'd like to see it fixed. So if we can start seeing this improve, great. Don, and if anyone else has questions, you should just feel free to step up. Yeah, so one of the things that was brought up a couple of times in the round table was the communication in two directions between the derivatives and the bug tracking system and the maintainers and the bug tracking system. And one of the things, obviously, since I happened to be one of the people with the Debugs hat on, one of the things that I'd like to see is better communication between derivatives who have their own bug tracking system and the BTS, both in terms of sending patches that are done for specific bugs, although Ubuntu is doing a relatively good job now of displaying the patches monolithically, it would be really nice to get the patches in such a way that they're sent to a specific bug when that particular bug is fixed. So the people who are making derivatives, it's easy for them to file even just wishlist bugs since you've obviously fixed the progress bar issue and you did that by making patches. And so it would be nice to have a series of bugs against the packages that you've patched with those patches attached. And at the end of the day, if it becomes a point that you need the TC or somebody to override it, the particular maintainer, you have got all the documentation necessary to do that. So those are two things I'd like to see, both better tie in. And of course, if anybody's using different bug tracking systems and you'd like to know or you need the BTS to do something differently, and it'll work better for a distribution, please let me know. Because it's something that I think all the maintainers would like to see. And I know that it would make the derivatives jobs much easier because the size of your diff would decrease every time a bug was merged back into Debian. Yes, I'd like to clarify that. Our project doesn't have its own bug tracking system. We're just making a front end for the Debian bug tracking system, which I think it's a good idea because we can manage all the problems in just one database, which is the Debian one. And the problem is that using email for communicating with the BTS is not the most user-friendly way for people who has not produced contributions to the project. And also- Just to interrupt there, one of the things that would be good is to increase the usage of things and tools like Report Bug or Report Bug NG in your user base. Because even though they use email to communicate with the project, they don't appear to be email-based in users. Yes. Also, Report Bug NG is a great project to base your ideas on. And also, I think that, for example, patches.ubuntu.com were maintainers of Ubuntu, or I think it's not the maintainers, but just Scott, which publishes patches there. Yeah, just, I'm gonna interrupt you again. Those are monolithic, though, which is the, but primarily monolithic. Well, I think- Okay. I think that we cannot let the derivatives to make the patches because sometimes the patches are not complete or they don't know how to make patches or they don't know, for example, I have seen people who has great ideas for a package but does not have any idea of how to do a Debian package or even a diff file. So maybe we can have a system which automatically compares the source package in both Debian and derivatives and publish the differences in a webpage or something. And actually, the problem that Kai said about being or not being a Debian developer also makes an influence because when you are a Debian developer, you are expected to have, for example, some sort of communication media, which is your Debian email or an iverseenic, so people can get in touch with you and ask you questions. When you are a derivative, you have no communication or there's no guarantee that you can communicate with them anymore. Okay. Just a quick comment on the use of the, all right. Sorry, just a response to Dawn before we go on for a minute. Few responses, actually. Firstly, while there are monolithic patches, there are also, I don't think it's been very well advertised, but there are per upload patches as well, so there's deltas between patches that are published to, and that can be quite useful. Secondly, I think, while we do publish that, I think ultimately we'd prefer everybody to be using distributed revision control for that, and we've put quite a lot of effort into developing BZR, constructing BZR imports of upstreams and so on in order that that has some chance of eventually being a reality. There are a lot of people working in this in different directions, so we'll see how it pans out. And thirdly, as far as the bug tracking system goes, we did, I remember we did talk a lot early on about whether we should have Ubuntu bugs automatically panted into dead bugs somehow, and the general consensus was that we'd get shot for being evil spammers, but quite possibly we should be doing something better in terms of selective propagation there. Yeah, I mean, maybe if the maintainers could, of the packages, when they see a bug that's obviously valid in both, could just duplicate it if it's not already there. Yeah, I mean, I suppose a way to pull could be implemented, and just have to talk about it with whoever wanted to do it and think it out. All right, sounds good. I think we have maybe one or two more. Yeah, I was just gonna say on the derivatives using the bug system, Mdebian just decided to use dead bugs as is, and just see whether that, using user tags, so we just tag all our bugs Mdebian and hope we can match them onto a Debian package, which will usually work, and that saves the whole problem of us having to have our own system and having to send them back upstream. Now, I don't know how well that will work, because that's fairly new and shiny, but I think user tags is quite flexible for that kind of thing. And in cases where it's not, I'm glad user tags. Any more questions? Time for one more. Oh, another comment, yeah, sure, sorry. One thing that hasn't really, it's not a question of coordinating between a lot of maintainers, but one thing that has been worrying me as a system administrator at the University of Oslo is that the Debian kernels are upgraded without changing the name of the package, so you don't really have a fallback kernel to boot if the new one doesn't work for you anymore. And this has been discussed last three deb conspice, and I think the kernel team is really interested to have it happening, but because it requires a sleeping time in the new list cube, it hasn't happened yet. I'm not sure why, and it would make it a lot more convenient to maintain a lot of machines if you always had a fallback plan when a new kernel didn't work anymore. I think that's less of a problem than it might be because really huge changes to the kernel tend to change the ABI anyway, so that does change the package name, but yeah, it'd be nice to have something that was a bit more fine-grained in that, ideally without filling up your slash boot over time as well. Thanks everyone for coming, and I think there's at least a couple good conversations that have been started here that we can continue, so. Thanks, and thanks to everyone on the panel who sat up here.