 Mae'r cymdeithas yn ymddangos? Felly ddim yn ddod, fyddai gyd yn gwneud. Rydym yn rhoi i fynd i gyd yn ymdag, os ydych yn ymgyrch yn ymdannu, yna ymdangos ddim yn ymdannu a'r hyn yn ymdannu ymdangos, sy'n fyrdd ymdangos o'r cymdeithas yn y cymdeithas ymddangos. Ymgyrch yn ymdangos i gyfnodd cyfrannu amser yma, ac, yn ymdangos ymdangos, dyma'r cyfnod a'r hyn o'i gyd yn ei grannu sy'n beth o bobl gyfan allan lleol, gobl wahanol gyda'r bywydau, y gallai wneud cyfleoedd yr unig. Esbytyddu'r bobl yn gyfweld a'r methefi gyda'r bywydau. Yn mynd i'n mynd fel gweld yn dweud ond fawr ar y cyflomau fel gweinchol fel gweinchol a'r bod dwy'n mynd i'n dweud gelwch gwael ac mae hefyd yn gobydd bobl yma. A rydych chi gweithio'r cwestiynau yn cael gallu ysgol i weld yw'n gwneud I will just weave those into the thread of the discussion. Hold on, I'm just trying to see if I can get my points up online. Are they up here? Hold on, okay. Is that... Are you getting anything on the video feed? Nothing, okay. Matt, can you move this over and I'm just going to bring my points up here so I can. Okay, so Helsinki last year was in what, June, July? And at that stage we had just pushed out Ubuntu 5.04 which was the Horry Hedgehog. That was the first release where we had sort of our own live CD technology. And the focus since Helsinki has been very much on the next release which was Breezy Badger 5.10, October 2005, and then The Road Through to Dapper Drake, which is now due out on June 1. It was originally due out to be May 20, but we missed that date and pushed back to June 1. So there were a couple of areas where we put in quite a lot of work in the Breezy release. In the installer we did some work around an OEM mode of installation. And I think Joey, that stuff's all being pushed up into DI, right? That's all... I believe Colin's pushed all of that stuff up. Okay, well that stuff should or certainly be in Etch, I would hope to see it there. And the idea there is to allow people to be able to do most of the installation to the point where they can actually test the OS, make sure that it's working, but without doing the user configuration stuff. So that this is very useful for resellers of hardware effectively. They want to be able to install an OS and then ship the boxes out to someone and that person will then set the time zone and the username and password and all of that kind of stuff. So that required some tricky changes to DI. We also extended some of the live CD work that we've done to be the basis for a new kind of thin-client technology. And we've been working on that with the guys from LTSP. We very much hope that that's going to become the basis of the next generation of LTSP thin-client technology. And Petra Rinalson, I think, has been doing quite a lot of work to make sure that that stuff lands in Davion as well. So the idea there really is to make sure that this image can basically be booted from any sort of device, or for USB stick, or for the network, or for live CD, so that you kind of abstract away some of the hardware dependencies of the installed OS. And that work continues in DAPA. We've focused a lot on the performance optimization of that because while we got it working for Breezy, it would take about a minute to boot whereas the LTSP stuff was booting in about 35 seconds. So we're trying to cut that performance down. So it's also quite a lot of work done on clustering in Breezy. Fabiona, I don't know if you guys know Fabiona. He's a big fan of clustering. So quite a lot of the Oracle file system stuff went in. Some of the Red Hat file system technology stuff went in. And I think there are quite a few people now starting to use that release 5.10 in clusters. That's not really a primary focus for Ubuntu because we've been so desktop oriented. If people are doing that kind of stuff with it, then it's nice to integrate it and make it sort of just work out of the box. Breezy was also the first release where we made some, we made multiple actual releases at the same time. And so Kubuntu and Egibuntu, which are desktop oriented releases focused on the KDE desktop first and education desktop environment second, those became kind of official. So the way we work is we divide the whole archive up into packages that we provide core security support for, the things that we will actually ship out security updates for 18 months for most of our releases. In the case of Dapper, it's going to be three years or five years for server type components. And so things, releases which consist only of software out of that core collection, we consider those kinds of official releases. And so in Breezy, Kubuntu and Egibuntu became official releases. We go to the point of treating them in exactly the same way as we treat the GNOME-based desktop. And I'm hopeful that with Dapper we'll actually get that right. So that if you're interested in KDE, you can get a Kubuntu CD in exactly the same way that you could get an Ubuntu CD or resellers and distributors can pre-install either the GNOME-based desktop or the KDE-based desktop as they see fit. And the last sort of big area of work that we did in Breezy was starting to build some kind of grassroots community-based hardware certification process. And that's really what generated the database that Max and Daria were talking about. That essentially is basically just integrating into the OS a sort of a hardware testing and validation component and then on an anonymous basis allowing people to submit that. Although they can use a cryptographic technique so that they can always go back and update their record once they've submitted it. But we can't trace that record back to them. And I think in the data that we gave Intel, we'd stripped out even IP address and timing information. So it was very much an anonymous data collection process. Okay. So the way we work is we have this sort of six-month cycle. For Dapper it's a little bit different because the goals for Dapper are a little bit different. And at the beginning of that cycle, we try and get all of our developers together for a conference. The last one of those was in Montreal in October. Ubuntu below zero. And the next one is in Paris on June 18th to 23rd. And you guys and any other DDs would be heartily welcome to come to that. The format is quite intense there. We really map out the roadmap for that release. And so there's a lot of debate and discussion that goes on trying to crystallize and identify the specific sort of feature set that goes into any release. In Montreal we basically laid out the roadmap for Dapper. And Dapper was the first time that we tried to actually go about pulling together a release that could stand up head-to-head with Red Hat Enterprise or with SUSE's Enterprise release. And that was obviously quite a substantial challenge for us because we'd been focused very much on the latest and greatest desktop stuff. And we knew that if we switched over to doing an Enterprise-style release, then we would have very different people that would be interested in that. We weren't sure how the community would react. We weren't sure whether we would be able to do the level of QA and debugging and so on. That was necessary for that. We'll come back in a second. So the goals for Dapper are quite different to our normal releases. We're going to support Dapper for three years on the desktop and five years on servers, at least five years on servers. So that obviously means that we'll have to do a lot more in terms of driver backporting and security updates for a much longer period of time. We decided to do this for this release because there's this really nice thing happening in upstream at the moment where the kernel is really well shaken up. Kernel 2.6 has really had a lot of stuff shaken out of it. You can consider it pretty much Enterprise really. All of the major distros are moving to 2.6 as a well tried and tested kernel. X has gone through a stabilization process around Zorg 7. And so the X that's in Dapper is pretty much the same as the X that was in Breezy with a few extra drivers, a lot of extra polish and a shift in the way it's packaged to modularize it and make it a lot easier, hopefully, to get community participation in X because traditionally it was such a monolithic, scary hairball that it was difficult to get community participation in X. OpenOffice is also kind of at a bit of a plateau. OpenOffice 2 came out just before Breezy. So OpenOffice 202 is not a huge jump. We know those packages very well. We can do a lot of QA on those packages. And so all the major GCC, we stuck with GCC4, which we pushed in in Breezy. So all of the major sort of components, scary things, we're at this nice sort of pause, this nice internal kind of plateau. So it seemed like a good time for us to do a release which we would support for a much longer period of time. So part of that part of Dapper is that we'll have a server edition. So that means that we'll have one image that people can download for desktop installs, and that has this shiny new graphical installer. The other image is a server-oriented image, and that uses DI so that it does all the sort of kickstart type things and sort of optimized install type things that you would expect for a server type environment, a text-based installer. That graphical installer is called Ubiquiti, and it's written in Python, PyGDK, and it's a little bit nerve-wracking for us to do an enterprise-grade release with a brand new installer, but so far the feedback on that has been pretty good. There's also an upgrade tool, because we found that even with the magic of apt, getting people to upgrade from one release to the next every six months, there were always little things, little kind of corner cases that apt in aptitude and synaptic wouldn't catch. For example, where we had changed policy, we'd shifted from using, say, ESD to polyp audio, and if you looked at the package dependencies, right, ESD and polyp audio both provide the same things, but if you just went through a straight upgrade process, you would end up with a sort of a breeziish system that looked mostly like a Horry, that looked like it's still inherited a lot of the Horry policies. So the idea of the upgrade tool was to start to be able to encapsulate some of the smart intelligence, the experience that we get from people upgrading from one release to the next, so that not only do you have the standard sort of apt layer doing its package upgrades and managing dependencies and conflicts and resolving all of that, but you have a higher level ability to go in and sort of shape that upgrade and say, okay, at a policy level, we're moving to this new version of Python, so you can actually get rid of the old version of Python unless there's something that indicates that that guy specifically wants that version of Python there, or he's installed other packages which specifically depend on that particular version of Python and stuff like that. This is the first release where we'll actually be sort of publishing all three Ubuntu, Kubuntu, and EduBuntu on the same basis, and so pressing CDs of those. That's going to be really interesting, because there's this very tricky relationship at the moment between GNOME and KDE, and I think it's actually vitally energising for the free software community to have these somewhat competing communities, because to a certain extent they play off one another's strengths, right? They focus on different things, so that means at different times people can go and if they're interested in different things, they can find a community where they can express that stuff, so GNOME, long time ago, made usability and simplicity and that kind of clarity of focus a very big priority, and the KDE guys went off in different directions. Now the pendulum's swinging, so they're much more usability conscious, because they actually have seen how that's really benefited the GNOME guys. So I think that that divide is actually a healthy thing. It's somewhat frustrating. It slows some aspects of the sort of global adoption of free software down, but I think it is kind of energising, and so we want to kind of let both of those desktop communities effectively feel that they can paint on the Ubuntu canvas or the Kubuntu canvas to make sure that those two desktop environments really reflect their kind of vision at the time of the release. So it's going to be very interesting for us to see, for example, what the real adoption rates of GNOME-based you know, GNOME-based desktops versus KDE-based desktops are at the moment, it's very hard to get any kind of hard data on that kind of stuff around the world, because most people are using a sort of a combination of both of them. If you look at the way SUSE has approached it or the way Red Hat has approached it, they've tried to sort of shoehorn them into a single unified desktop. And so we kind of recognise the differences and try and give those communities space to run with that. Edubuntu is going to be interesting. One of the big challenges that we have coming out is that there's a whole explosion of low-power devices that are emerging. And these are going to be very interesting environments to actually target from a platform point of view. So, for example, a $100 laptop is one that's kind of an idea that has really captured people's imagination. And whatever comes of that particular project, I think what's fantastic about it is that it's really challenged the entire industry to say, hey, what can we do in emerging markets? How can we turn Moore's Law upside down and say, instead of just trying to say, Americans will pay either $299 or $399 or $599 for a PC. How much functionality can we get in this year compared to Dell, compared to HP, compared to IBM? Instead of that approach to Moore's Law turning it around and saying, hey, here's a basic minimalist, very functional computing environment. How cheaply can we make that this year? And so I think that's opening up a whole raft of interesting R&D and opportunities. I think Debian is really very well placed to be part of that whole explosion because it really is this environment that you can... It's very malleable. So I think a lot of the people who are doing work with those kinds of environments are working with Debian-based platforms, whether they're Ubuntu, whether it's another derivative, they're starting in this kind of universe. And I think, as a community, we should really continue to encourage that. So I think the challenges with Ubuntu are going to be to try and figure out how you make an educational desktop work in these extremely constrained devices, but then also make it rich and functional in classrooms where guys have more powerful, more sophisticated computers. We're also going to introduce Ubuntu, Xfce-based desktop in the next release. Now, it's kind of... Ubuntu for DAPA will be pretty much the same place that Ubuntu was for Breezy. It will be supported in the sense that we're going to commit to providing security updates and so on for the Xfce-based packages, but it won't be kind of pressed as CD images and so on because it's our first release and we don't yet know that we have a close enough working relationship with the upstream community, the Xfce community there. But that will be, I think, Xfce 4.4 or 4.3 release, 0.90 or something. So it's a very, very current version of Xfce. So we learned a couple of things from a release management point of view. Originally we thought what we would do is we would do a standard six-month cycle, but we would just commit to doing fewer features. And that way we would give ourselves more time for quality assurance and so on so that we could get something that we could be happy to support for three or five years. But it turns out that that was just too difficult. We also found at the end of the process that we wanted to do more work on localisation, specifically around Chinese, Japanese and Korean sets. So we brought in guys from the skim community and we brought in guys from the font community. We brought in guys from OpenOffice, Firefox, GTK, and I forget the name of the KDE font subsystem to try and make sure that we can really get those character sets working well on this release. That required us to delay a little bit. So in all of that we learned that effectively if you want to bring in the latest desktop releases, the latest GNOME and so on, and you still want to do that extra level of quality assurance, then you just have to make that a longer release. So if we do another dapper in a couple of years' time, we will probably just learn from that. We will just make sure that we just give ourselves extra time and just plan that, build that into the planning process for a long-term supported release. So one tricky question we have is what we're going to do for the next release. Like, do we make that a six-month process and now we're sort of effectively two months behind GNOME and the other distros? What we've decided to do is actually make the next release a much shorter one. So in the next one we're actually going to catch up all the time we lost in the delay for dapper so that the next edgy, edgy Ft, will go out probably in late October. So that would be in sync with the GNOME release cycles as we have been in the past. In this last cycle there have been quite a lot of infrastructure changes. We've been working hard on some infrastructure. Some of that shows up in Launchpad. Some of you guys may be familiar with the scarily proprietary and very controversial Launchpad. So we've shifted now all of our bug tracking to Launchpad in the form of Malone. The reason we wrote our own bug tracker was because we're in a very unusual situation in that we need to keep track of your bugs. Essentially we need to be able to know when we're tracking a bug if that's also a bug that Debian's working on. We also need to be able to track upstream as well. We couldn't do that with Bugzilla or with Debugs at the time so we built Malone into Launchpad. So basically what that allows us to do is if we find a bug and we can find that that bug has been reported in the Debugs BTS then inside Malone we can say this is the Debugs bug number for that bug. And then if the Debian maintainer fixes that bug then we will automatically get notified of that and we can pull that fix in. I'd like to get it to the point where we can actually have a sort of seamless conversation between the Debian maintainer for a package and the Ubuntu guys who are working on a particular bug so that it doesn't really matter which your preferred bug tracking environment is that you can actually just have this conversation directly. We had a bit of a social problem in the community effectively where we had Ubuntu guys filing bugs in the Debian bug tracker and that I think we've quite successfully reduced the volume of that. I'd be interested in feedback from you guys. So hopefully when we do come into the Debugs bug tracker and sort of say we found a bug in this package what you're getting is information that has been vetted and has been reviewed by a developer so hopefully it's a high quality source of information and shouldn't result in large numbers of dupes and things. I think a lot of the things we have to try and get right are those kinds of social collaboration type things. So we've been working quite hard, for example, to educate the motifs. There are now 170 members of the Ubuntu community who can make contributions of one form or another. These 70 of those are developers making, adding patches and modifying packages on a regular basis. Only 15 to 20 of those work for Canonical and of course all of those guys are typically DDs who've joined Canonical so they are very familiar with Debian's processes and working and so on. So one of the things that I'm quite keen to do is make sure that as new guys, people who haven't been DDs previously come into the Ubuntu community who appreciate the importance of working well with Debian. There are a couple of things that potentially you guys could do that would help that and the number one thing of that would be to make guys feel welcome, right, so that we don't create artificial social barriers and remove the incentive that some guy has who's contributing to Ubuntu also to make sure that he does the right thing with regard to Debian. We've also now finally, after quite a lot of development, brought up Rosetta as our official translation infrastructure and there's been some discussion of whether or not Rosetta should be used by Debian as well. I've never proposed Rosetta for Debian because it's not DFSG free so it would be inappropriate to do it. But I know that there are many individual Debian developers that do use it and I would say that that's right as a personal choice. It's like using Google or not using Google, right? It's a web service you either decide to use it or not to use it. I suspect it's not appropriate as a sort of institutional choice effectively. What Rosetta is is a web-based translation front-end effectively. So you can upload a po-template to it and then people can start translating that po-template into different languages through the web and then you can download the po-files. So there's no real, you know, there's some concern being expressed about lock-in there. The system is only actually useful to the extent that people export all the interesting data from it so quite a lot of upstreams are starting to use that now and it's there as a sort of service to the free software community. Okay, our next summit to which you guys are all very welcome is June 18-23 in Paris and what we're trying to do with those summits is get in interesting guys from upstream. I hope we'll have some guys from the Mozilla community there, some guys from the OpenOffice community, some guys from GNOME and KDE, possibly also X. Or Colonel. So interesting guys from those upstream communities because what we try and do at a summit like that is especially with edgy, what we're going to try and do is figure out what all the sort of scary, interesting new technology is that is coming down the pike and is going to get pushed into edgy. So what we've traditionally done with our releases and more and more so as we got closer and closer to DAPA is we've identified sort of from the top features that we really want to have in the distro and then driven those down and assigned them to developers. With edgy, what we're doing is turning that process upside down. So I've promised not to mandate any features for edgy. Instead what the canonical guys and the other developers are going to do is nominate their list of five or ten sort of scary, cool crack that's coming down the pipeline in Colonel or X or OpenOffice or elsewhere and then they're going to sort of integrate that into the distro. So essentially we'll let the pendulum swing all the way back from instead of being sort of very conservative, rigid and boring to let's embrace some of the really interesting stuff that's coming down the pike. So the sorts of things that I think we'll see in edgy are probably Zen. I can't guarantee anything because this is totally dependent on one of the developers actually really, really wanting to have that feature. But what you could think of this as about is you can think about it as an entire release like Devin Experimental, right? Where we will bring in all sorts of experimental, exciting, interesting, difficult, tricky new technologies and integrate them into the release. And then over the next three or four releases we can consolidate that work and polish it up nicely. So Zen I think is a definite candidate. There's a lot of interest in optimizing the boot process. So potentially introducing boot dependencies so that you can say right once you've got a network up then you need to bring up this and this and this and so you can essentially have trees of dependencies. So the system initialization process we think can be optimized over there. So if you're interested in that then that might be something you might want to collaborate with the Ubuntu guys on. Yes, 20 minutes. There's some interest in multi-arch. There are a couple of proposals floating around in the Devin world right now. We may or may not actually choose to run with one of those proposals. The guys to talk to are Tolliff, Mithranda and Keybuck, Scott Remnant. So multi-arch would basically allow you to have a 64-bit system which can up-get install a 32-bit package and then it will go and fetch all its 32-bit dependencies and maintain lists and sanity between its 64-bit libraries and its 32-bit libraries. So this is actually quite important if you want to have 64-bit desktops. It doesn't matter so much for 64-bit servers because you're only running a database that's a damn thing anyway and you want the 64-bits there. But where you've got sort of developer workstations and so on where you might want to have a 64-bit application but you don't want VI 64-bit or you don't want sort of g-edit to be 64-bit then it's nice to have that duality built into the infrastructure. A lot of talk of XGL and AIGLX kind of the whole wobbly windows, transparent windows, compositing and all of those kinds of technologies. I think those are still at the level of edginess and it doesn't make sense for edgy rather than something we could have shoehorned into into DAPA. One potentially challenging transition that we might make in edgy is to adopt SMART, the SMART package manager as a replacement for APT. We certainly haven't taken a decision on that but there are some guys in the team who are quite keen to make that happen. And we do Gustavo Niemeyer who is the sort of author of SMART and is now on the canonical team as well so we might well do that. Just some words on the WTO community. Now about 170 people, about 7,000 translation contributors. We've almost had too much success on the translation contribution thing because the way we structured that is we let people create language teams and then anyone who's on those teams could contribute translations and some of the language teams just exploded up to like 100 people and with no kind of quality assurance added. So we've had to sort of tell everybody, it's more important to get high quality translations than to get lots of translations. So that's something that we have to sort of address in the community. We got about 150 bugs a day filed now which is great to have guys out there testing and filing bugs but it is pretty, the fire hose effect is starting to kick in. I don't know, what do you get in debt bugs typically a day? I think it's almost comparable at this stage. Yeah. One thing that I'm really happy to see is that there are a bunch of, we're starting to see derivatives of derivatives, right? So Nex Center was an interesting one, controversial but interesting. They're the sort of government ones, Squadra Linux and Mo Linux and then some sort of specialist ones for specific sorts of vertical markets is one on multimedia and some other interesting one popping up. I thought one thing that would be useful is to tell you a little bit about the way we appoint developers. We have two kinds of groups of developers. The Masters of the Universe, the Mo2, which is kind of a mentoring environment. That's where new developers come and they work with the Mo2 effectively on new packages, fixing bugs, packaging up new things. Those are the guys that we need to sort of invest the most work in terms of getting them up to speed as what packaging is all about, how to interact well with upstream, with Debian and other distros and so on. If your package for example is not in main, then those are the guys that you want to talk to in Ubuntu if you want to make sure that your package is being well treated and well handled in Ubuntu. There's a different group, the core group which handles the sort of the inner subset. So that's all the stuff involved in the boot and system initialization process is the kernel and the sort of core supported desktop applications as well. So those processes are entirely open to Debian developers. There are quite a lot of DDs now that are also members of Ubuntu. Doing so allows us to reduce the risk of divergence between Debian packages and Ubuntu packages. There have been a couple of spectacularly bad examples of a package which existed in Ubuntu and then someone came and sort of ITP'd it for Debian and we sort of said, hey well you can take this package, it's already there and already works. No, I don't like CDBS, I'm going to go do it again from scratch using a different system. And the same things happened in Ubuntu where there's been a package in Debian and a Mo2's come along and said hey, no, I want to completely redo this package. And we want to try and reduce the incidence of those things. But I think it is worth pointing out that it's something that happens equally on both sides of the aisle over here and we both have a shared sort of common interest in reducing the extent to which that happens. There are some highlights and some lowlights in terms of Debian and Ubuntu collaboration. I think Atnubu is great. It sprang up after Debcons last year and the idea is to have a team in Debian that actively takes responsibility for finding interesting stuff that's in Ubuntu that's been added in Ubuntu and bringing that into Debian. And I think that's really awesome, I'm very supportive of that idea. One of the things we try and teach new Mo2 guys is that they should let the Atnubu guys know if they make an interesting change or something that's particularly worth going and looking at. You know that we automatically publish out all the diffs, all the deltas and I'm honoured that Joey and others have gone through and sort of done an analysis of that with varying results but still I think it's good that guys are going in and looking at those and we appreciate that kind of review and feedback. I'm very pleased to see Zorg landing in Debian. I think those are a sort of a continuation of the work that was done in Ubuntu and I think that really highlights one of the things that we can do very nicely is bring new chunks of infrastructure in, get them stabilised, get them working, push them out and then have them land in probably in a more gracious kind of fashion in CID and then in testing and in a Debian release. I think there's good collaboration now in the DI front. I know that Colin works quite hard to make sure that that's the case and I hope Joey's happy with that. For example, I think we did a lot of work making those C++ transitions easier, right? Once we've done it for all of what we call main, all of those patches are available and then we've seen that those C++ transitions get more painless in Debian because you can go get a full set of patches that consistently across all of the core packages makes a C++ transition easier and we've tried to be good about making sure that where there are tricky decisions or arbitrary decisions like package naming for C++ ABIs and transitions like that, that that's done in collaboration with the relevant Debian team. OpenOffice.org, the new Java packages, there's been some good collaboration on those. Some lowlights, Amaya. The fuckabuntu t-shirts. Please tell me how that can inspire and motivate an Ubuntu developer or a new Ubuntu developer to want to contribute to Debian. What's that? Are we going to have this conversation now, Mark? No, we don't have to, but I'm just pointing out that something like that does make it difficult. This fuckabuntu t-shirt is the same thing as registering the Ubuntu domain name. The same day, a bunch of people in Debian that wanted to do this, the same day we mentioned this project, the domain was registered, we failed a little bit raped, but we could go on and on with my list of rapings, like internet. I think the most important thing though is to try and make sure that we have an open conversation. No one has ever approached me about any of the things that you might mention on a list there. I guess the thing that I want to highlight is that you can approach me directly. I see a lot of the time, I do read email and I will get back to people on specific issues. You can approach me directly or you can approach one of the community governance structures or if it's an issue around the technical structuring of packages, the community council, if it's a social kind of issue, we have that sort of divide different groups looking after different things. If you feel that something's not being done well in Ubuntu, please raise it with us, because it's really important. Yes? Yeah, let me... Will you take one over to her? Thanks. Because I think we'll find that almost everything that comes up is stuff that we can resolve reasonably and find a healthy way of collaborating. I've always found that it's better to have a conversation about stuff than to take steps which make it difficult for people to feel excited about collaborating. I guess the one thing I really want to impress on you guys is that I can't force volunteer Ubuntu contributors and developers to go the extra mile to be nice to Deleon. I can inspire them to do that. I can tell them that I think it's the right thing for them to do. I can strongly suggest that they do it. We can make it part of our codes of practice and codes of conduct and so on, which we do. But it's very hard for them to really want to do that if the feeling that they get is that their contributions are not welcome or that they're belittled or rejected in any way. Okay, so just wrapping up. Margarita. No, you need to unmute it maybe or turn it on. Maybe there's a mute button. So my question is about Launchpad and Rosetta. We've been asking about this for a while now. We would like to know if some time Launchpad and Rosetta will be released as free software and if that's some time maybe like real soon now. So the answer is yes and no. Launchpad is proprietary because there are some services that we want to offer to companies who make derivatives of Ubuntu, right? I believe that there are lots of companies out there who spend a lot of time redoing the same work over and over and over again and so through Launchpad we can make it easier for them effectively and we'll offer that to them as a commercial service so that we can integrate tightly with them. They can produce a better derivative that has better security, update support and so on. So that's why Launchpad is a proprietary piece of software. It's part of Canonical's business strategy and Rosetta is integrated with that because Launchpad already knows about the distro effectively knows about packages and it knows about all of those sorts of things so it's fairly easy for us to bolt it onto that. We have already released pieces of Rosetta to the GNOME translation project and so on so some of the stuff that the GNOME translation project uses for rendering web pages and stuff like that is what we wrote as part of Launchpad and of course all the stuff, all the underlying plumbing a lot of the infrastructure, the changes that we make to SQL object PG SQL and so on all of that stuff is released. Over time that set of services is not going to be strategically useful something is only strategically useful for a couple of years and so over time we can release anything that's not strategically useful and so I'm just Margarita you asked the question I'm just kind of painting the picture for you there. Yeah, this is done. Manoj, go ahead. I'm stepping back to when you asked for feedback if you're really serious about this and I assume that you are the forum for this is unlikely to be on Ubuntu IRC channels or mailing list. I'm a WN developer been here for a while there are 96 derivatives at last count when I looked that flow from Debian. I don't have the time to go to 96 different set of people and tell them how we can improve collaboration. It would be nice if we all did but one of the things that is I think should be in the code of conduct for it should be in the Debian developer's references how we treat upstream I personally when I have a upstream developer if there is a bug that I discover I feed back to their BTS I don't put it in Debian's BTS until the make developer hey go look up there I put it in the make bugzilla I triage bugs that come into me feed it there any responses that happen on make I feed back into Debian I'm not seeing anything similar happening on a bug by bug basis for my packages in Ubuntu yes there is one gigantic patch from when my package was synchronizing to Ubuntu which contain changes that I have made already for Debian so it's not it's not restricted to the patch the giant patch is not related to either a single bug or something which is current in Debian unstable when I put in a patch for make I make sure that it is against the release version if I go against the CVS I update my patch and I feed it back to the make developer so I think you certainly should be seeing bugs being filed in Debugs BTS that are also being tracked in Ubuntu because we have all the infrastructure to support making a bug in the Debugs BTS and linking it to our bug tracking infrastructure so you certainly should be seeing that and I guess it depends on who the specific maintainer is who's covering the packages that you're responsible for and there's a bunch of guys here Matthias, Matt, Simon there are a bunch of other guys here who work regularly on Ubuntu so feel free to have that to engage with them and to make it better over time it's also it's also fairly easy to find the relevant person in Ubuntu who's looking for a particular thing Joey just a couple of things there was the maintainer field debate I'm glad that we had the debate and that a decision was taken I would like to ask that that decision be projected as something that should apply to all derivatives and not just to Ubuntu we'll certainly implement it during our next cycle so that what we will do is change the maintainer field as requested by the Debian community to maintain a field of the package in Ubuntu to reflect the person who modified it in Ubuntu rather than the Debian developer I should say a couple of things first, no other derivative has ever done it that way so I think if we're going to make that change then it should be something that we push through and also I should say that I don't like I kept quiet during that debate but I don't like lossy changes it seems to me that information is valuable and I would far have preferred a solution which said okay we'll upgrade the maintainer field so that we can effectively keep track over time of here's the maintainer in Debian here's the maintainer in Ubuntu we're living in this more and more general universe where you've got derivatives and derivatives of derivatives and really what you want to be able to see when you look at the packages who are the set of people who've been involved in producing this ultimately all the way up to upstream okay that's probably just about all that I'm going to get to Joey you had a question earlier you asked about the Debian installer OEM stuff and I guess it's probably all in there and this sort of feeds into I think you're doing really great with say for example the Debian installer pushing the changes back however I'm afraid that's only half of the picture because we have the OEM installer stuff in Debian and yet people were asking me the other day I want to do an OEM install with Debian how do I do that and nobody knew how to do that so my question is okay let's assume that we get things straightened out you're pushing patches back that's only part of the picture the other part of the picture is integration the talk before you which I don't think you were here for had a slide which compared Debian to a supermarket where you go in and get raw ingredients put them together, get your distribution and compared to Ubuntu to prepackage food or something like that where you get an integrated thing and so my question is that Ubuntu has directed a lot of the energy about integrating different things be it OEM installers and lots of different areas has been directed to Ubuntu and this does tend to relegate Debian to being more of a supermarket and my problem is that I'm not interested in being a supermarket particularly I enjoy working on that area but I also enjoy working on the integration and so my question is how can Ubuntu push those changes back I think you see what I'm getting at here I think the answer to many of these things is social processes that's why I was so happy to see Atnubu pop up because in theory this is a Debian team that can know how to communicate and how to go and change the relevant web pages how to go and tell the relevant people how to do a mail to Debian developer announce whatever is the appropriate way of projecting, I think you're talking about actually projecting the knowledge of what's been contributed one of the things I get very frustrated about is that I don't think Debian guys sometimes realise how much is currently flowing into Debian that's essentially entirely driven by what we're doing at Ubuntu which is entirely part of the vision of what we're doing at Ubuntu the vision behind Ubuntu is that it stretches the Debian family out so that there is a release of Debian which is totally optimised for these simplistic use cases and that that code flows back but that Debian is able to encompass that in terms of other architectures other use cases, other scenarios platforms, approaches, priorities and so on so Joey I absolutely hear you maybe some comfort to realise that a lot of people didn't realise that that technology even existed in Ubuntu because we were bad about just documenting it in Ubuntu that wasn't deliberate it's just because we were busy and it's a hectic schedule okay I guess we've got I have another question can you say something about TPL violations about like kernel drivers and stuff okay I can categorically say that we don't believe that we violate the GPL so I think what Andreas is referring to is that we include binary drivers in Ubuntu we link those on boot so there is no at no stage any compiling or intermixing a mingling of code during the production process you could in fact produce these different bits on entirely separate machines without the relevant GPL code and so on so we then link those dynamically on boot those are stored on a temporary partition so that they can't accidentally go on to your hard drive so that if you sell your Ubuntu laptop to the next guy you're not actually redistributing code which has been linked against GPL code so this has been very rigorously Andreas has been very rigorously analysed legally tested consultation with people from different aspects of the community there are some people who don't like it or Ian and others don't like that we do that but we specifically look very carefully through that process to be able to take that step and still remain in good standing with the GPL community I'm told at times up Simon from Sun asked if he could just have a quick word at the end of my talk which I'm very happy to do and let me just close by saying thank you very much thank you for the questions tomorrow but I'm back here most of Wednesday Thursday Friday Saturday and enjoying being here and thank you very much for your hospitality and friendship Thank you very much Mark for yielding a few minutes I did want to bring you some news that is going to be announced at Java 1 tomorrow but it's very appropriate for it to be announced at Debcon first because it's a work that's involved the debuting community now you're hoping I'm going to announce that the Java SE is free software and it's not yet so keep on holding your breath but I had a nasty experience earlier in the year I wanted to run a cron job on my server at home and it needed to have the JRE installed and I found that there wasn't a package that got a JRE installed that would make my cron job run so I went to the Sun site and there was a package there and I discovered that it was actually there's probably young people watching so I mustn't use the words that I would like to use about it but it wasn't a very good package and if you've had the misfortune of having to engage with the Sun Java installer in the past you'll know that it was really not a very good package the reason that Sun Java was not in non free was because the license associated with it dated back to the days of the dinosaurs and I'm referring specifically to the dinosaurs you see in Microsoft advertisements at the moment and consequently it had three ugly clauses in it that prevented Sun Java being included in non free it included a clause that cascaded liability to the Debian organisation for their users behaviour it included a clause that prevented shipping Sun Java with anything intended to replace or substitute Sun Java and it included a clause that said that you could only ship Sun Java with a more major Java program and all of those were obviously completely unacceptable to a free software community so what a few of us have done is we've got those clauses out of the Java license and we've also got together with people like Geron and other folks, I'm going to get Tom to just come out and say who was involved and as of now you should find that there is a full Java package up in non free or it's propagating out to the mirrors so that you no longer have to deal with the ugliness of not having non free Java available in Debian the other thing that you really want to applaud about I'm still working on so please give me time I desperately want it to happen one last thing is if you think this is interesting and you want to blog it I would be very grateful if you didn't blog it until after 9pm Pacific or 11pm time here and the reason for that is because I'm living in this furious warp world between sun PR people and people who actually know about code and the sun PR people are desperately keen for this to be news tomorrow morning so if you could hold off in talking about it until after 9pm Pacific 11pm Mexico time I'd be very grateful but ultimately well it's up to you what you do Tom can you just say a few words about this because we're now at minus why are you on camera yeah I know but the only people who are watching the camera are very responsible Debian community members so first of all I'm Tom Marble from Sun Microsystems I've had the opportunity to meet a handful of you and I only wish that I had been able to register for debcomf early enough to get my badge and all that in time I actually was approved to come to debcomf on Tuesday so I'm actually thrilled that I'm able to come here and thank you when I learned that Simon was working on fixing the Java license and in particular was working with Debian I was really thrilled and decided to more or less stop doing my day job that I'm supposed to be doing and I focused on this and regrettably most of the time it's been spent dealing with lawyers so I haven't had as much time to deal with technology as I'd like but I do want to say that in the past couple of weeks I've worked more or less around the clock with Yron and Barry Hawkins who are responsible for the Java package and also Matias Closa who has helped with the packaging and I also want to recognize the contribution of Diolch yn Clydda for some initial packaging and I've learned a ton about Debian policy and FHS and Sun has never ever ever done this kind of a thing before letting a distribution blow our bits apart and put it into FHS the way that you guys want to see it and by the way it is integrated in a very awesome way with Debian and I really hope that this will be the beginning of a great collaboration as Simon mentioned yesterday there's every reason for us to be friends and I look forward to working with you in the future and I hope to become a Debian developer so thank you very much