 It's actually about porting parted, so it's still a big part to do. So maybe help is a bit needed on that. And the other stuff is finishing parting busybox for all the network related tools. So if you want help on that, you can ask on Debian Boot or Debian BSD or also on the IRC channels. Good morning, everyone. My name is Sha Liu. My mentor is Anthony Folk, but you can see there are three people there. So the other two is the co-mentor. In short, the goal of my project is to compel packages with, you can see, MRQ equals to MIPS 3 and Lonson 2F and with MABI equals to N32. Well to finish this job, first I need to build a MIPS 3 minimal Linux system using CLFS method. The CLFS is a project teaching people how to cross-compel Linux from scratch. Second, I'll devinize this system by building Debian packaging system includes DPKG, APT, etc. Then I'll build packages in a stable archive one by one. Well now I have already had such a minimal system with the new two-chain. You can see band new two is 2.19, GCC 4.4, GDPC 2.9, and with the kernel 2.6.29. And many patches are already available in Zhang's overlay. This, you know, Zhang is a Gen2 developer, so this is his overlay. For the to-do, the to-do list is much longer I think. First I should finish building DPKG and all its dependency. Then I'll devinize the file system. Third, I want to try MRQ equals to Lonson 2F. For our test performance between this new system and old Debian MIPS EL port. Fifth, I want to run this new system on the GDM Liberty 1000 netbook. Well, there are many things you can help with. You can test this minimal system. I've already uploaded to this FTP. You can always subscribe to this mailing list to be part of it. And there are many practical problems I've encountered in working on this project. For example, how to automatically devinize the file system as Debian portacy manual suggests. And how to efficiently get all dependency source packages. And finally, maybe you can help me build a package or two. Well, you can see this is my development block. And this is the method I use to build this minimal system. And the last is the homepage of GDM OLPH program, as you may know. You see, the left picture is the GDM netbook. If you register to be one of the developers, you can get this netbook at a lower price. And on the right is the black box, the full-on box. As you can see, the size of it is almost the same as CD-ROM. Well, that's all. If you have something interesting, you can always contact me. Thank you. So next up is the project of David Wendrinner, mentored by Stephen Moller. The goal of this project is to create tools to work with the Amazon EC2 system. So this system is a cloud computing system. It has nothing to do with Google or anything. The idea is that you can have hosting, and this hosting can be extended and simple clicks. Say you host a website, and you have one server, and suddenly you open SlashLot or whatever, and you can order 100 servers exactly the same and not balance. It also has uses in academia, where it is used for computing, whereas universities set up clusters of computers for use by other universities on demand, which is why a project was initiated inside academia to create a clone of all the Amazon infrastructure with free software. So because Amazon have restrictive license on the tools they provide, we can't use them directly, legally, with a character. So we've been working on recreating these tools with free license and more friendly functionalities so that anyone can set up a cloud computing cluster at home or whatever. So the status of the project, Eucalyptus already has Debian packages, but these packages are not really following Debian policy. So David has been helping them to create new packages that actually comply with Debian policy. He's been helping with tools, these tools, these free tools to replace the Amazon tools. He's also working on Porting VM Builder, which comes from Ubuntu. Ubuntu, through Canonical, has a commercial partnership with Amazon. So they created some specific tools which have some Ubuntu-specific functionalities, like working with landscape commercial computing management, which is not useful to us. So basically, we wanted to work with Debian, with the whole Debian environment, Xen, Virtual Box, whatever is needed. The code is in alias, fully ported to Debian, we can try it. What's left to do, we still have to pass a few modules that are still a little too much Ubuntu. We have to validate kernels that are provided by Amazon, because Amazon has a set of kernels that you have to use, you can't use Debian kernels on it. So we have to validate them, and Eucalyptus signs, they're still worked on, left to be done to comply with Debian policy, so we can have packages by the end of the summer inside the archive. You have a few links, you can follow them up to the end after the talk. This project is to port back the update manager. The update manager is this little icon that nobody looks at, at the top of GNOME, which tells you you have to update stuff, which you don't never read. It's useful for Ubuntu, and they made a lot of customizations to support the LTS and other Ubuntu-specific stuff. Unfortunately, there is a lot of outcoded Ubuntu dependencies inside the code, there's hardly any documentation. So we want to port it back to Debian and to make it distribution independent so that it can be used by Debian or any other Debian derivative, not only Ubuntu. We wanted to have a cleaner design and cleanly separated between front-end and back-end, and have the ability to extend to support specificities of other distributions, such as those that are made for networks or specific machines. So if you don't remember, it's this piece of software. This new design is a comprehensive front-end back-end and this distribution-specific part, so that there is no specific part needed to port it to another distribution except writing plugins. There is new documentation that will be automatically generated, and we dumped calling synaptics with a very long common line to install stuff, and we dumped it in favor of the Python APT back-end that's been developed at Debian. We have some automatic distributions detection and new functionality so that it works cleaner if there is no GUI involved and so on. So to do front-end that will work on the common line, newer daemons that works cleaner, and some integration works with Python APT, we're working the Insta-first in testing. You can help. You will look at these slides later. This last project is to rework the BTS with a new modern web UI. Unfortunately, Diego is apparently ill, he's here, he might come back later. He's mentored by Margarita Monterola. The focus of this new project is to have better usability, something that's easier to use more friendly than the current BTS, which asks you to write mails in a very specific syntax, otherwise it won't do anything. It makes for easier triaging inside Debian. Right now, if someone just wants to do triaging of bugs, it's very complicated. The BTS doesn't make it very easy. It makes possible to create new workflows, creating, as I said, the role of a creator, separate from the maintainer of the package or the user. And of course, this new interface looks nice. So right now it looks like this. You can have this list of bugs. It's quite clean and written with CSS and standard compliant HTML in Python. That's the view of a single bug. You can have any actions. Most of the regular action can be done inside the interface without resorting to email. So what's left to be done? So some of the actions are not implemented yet. Diego still has to implement them. He still has to see what's to be taken from other BTSs. Right now the launchpad has just been open source. So he will look at the source code and see what's interesting to take back from them. And also he wants to integrate these new features and decide how to handle the choice of having or not user authenticate, how to have them authenticate and so on. Currently one of the issues with having entirely web-based bug tracking system is that developer fears that it will reduce the quality of the bug reports. And the other hand, if you force a user to authenticate and create and have a complicated registration process, you're sure that the most dedicated user will stay at the end and provide you probably better bug reports. So a balance has to be found here. So let's have a round of applause for our students, which are here or not here. So to conclude, the factor of success. You have to remember that not only the students are to be regarded for their success, the developers inside Debian also have work to do to make sure that their work will be successful. So how a student can turn into a future great Debian developer? First, you have to make sure that he wants to stay. So his project has to be properly integrated quickly at the end of the summer of right after. Google doesn't really care if the project is integrated at all, but we actually care. And the students especially care about this. We want their project to be fully integrated in the next release, in the stable branch. For these students to feel that their work would be useful and to possibly iterate over it to improve it, you have to contribute feedback to them. The students doesn't have to work in their corner alone. You can contribute to their work by providing them feedback, trying out their project, and talking to them face to face for those who are here. One thing that is interesting during this past four years of this summer of code is that many summer of code admins are past students who are here. Many of the current admins actually are past students. For example, the current project leader of Droomla, I think it was Droomla, was a student from the first summer of code who had actually never participated in the program before. So I think that the summer of code is a great stepstone for anyone to participate in open source programs. And these students who successfully participate in the summer of code inside these organizations make great ambassadors for the project inside different communities than what the usual audience of their project is. And at Debian, I think that they help show the welcoming part of Debian. So how you can help? You can talk to our students, know physically on IRC, for those that couldn't come, you have this IRC channel, Debian-soc. You can try out their project, most of them have something to try. For next year, I'd like you to think about great ideas to propose for students to do. The more ideas we have to present, the more students that we can attract. Also, you can talk to current and past mentors. We have a lot of mentors that participated in the program during these past four years. So you have a lot of people to talk to about what it takes to be a mentor and what's going on about it. Also, you can help add in the summer of code program. That's a lot of work to manage your program and all the mentor students involved. I think that the Google Summer of Code at Debian is already quite great. So I would like to thank all the students who participated in the program this year and the past years. All the mentors who gave great help to all our students. The whole community at Debian who helped review project and try out this project during this summer and of course Google for funding this project. They spend close to five million dollars each year on this project and funding and sponsorship and so on. So let's make a great experience for the students and the community and this summer of code will be useful to us. You have this link where the slide will be present, all these links and you can try it. That's it. So we have 10, 20 minutes, 10, 15 minutes left for any question. If you have any questions for specific projects or the management in general, feel free to ask them. Hello. Christian Perrier talking. It's more a comment first and then a question. As a comment, I would like to enhance the amazing work done by Arthur particularly in animating this summer of code. I've been watching this from the outside in the mailing list, et cetera, et cetera. I think and probably all the people who animated this in the past year will approve. This has been the best animated summer of code in Debian ever. So I think Arthur deserves a particular thank you from all of us, all of Debian for this amazing work here. He has been doing all along this summer of code and he will be doing all along this summer of code. So thank you, Arthur. Thank you very much. I think he deserves a special applause for that. And actually the question is very simple. Arthur, will you be running as a summer of code animator next year? Except if I'm dead, I expect to still be here, yeah. So that will be a great summer of code. Thank you. While I haven't participated in the Debian Summer of Code, I have, I mean the Google Summer of Code in Debian. I have done it in other projects and if you could back up a slide or two, you had, yeah, that one. I wonder what you could tell me about, are you looking to get students to contribute their code once they've completed it or are you hoping to let them, to get them involved in the project and committing it to revision control inside the project while they're working on it because I've had some, I had some experiences with students who did a great job but then it never actually got in and I think that if they're actually working in revision control the whole way along, it's helpful. So I wonder if you could go through some of the projects and just give the status of that. So at the beginning of the project, what we requested from students and their mentors this year, is to provide us RSS feed of their commit logs. So we have RSS feeds of most projects that can actually provide one. Some projects are not very ready to provide RSS feed because they work in individual packages and so on. But for the most part, we did much better for this year to integrate them live. Most students are working in the VCS of their respective project either on the trunk or on a branch. And we had all projects be hosted on Debian Infrastructure. So we specifically asked for the VCS to not be hosted on stuff like GitHub or a particular personal server so that we know where they are at the end of the summer. And we made great efforts also to notify any people that is involved with work related to each project. So we don't have any incidents like last year where one project just sent to the maintainer of the package one big diff. And that couldn't be integrated because of conflicting work. I hope that we don't have any incident like this this year. Any other question? Anyone has an idea of projects that you would like to have done next year? I hope you have. Well, great. We'll finish later in advance.