 Lukas Nussbaum, the current Debian project leader will deliver the bits from the Debian project leader now. Enjoy. That is your... Is that... Yeah, okay. Thank you. Okay. So, to start, I wanted to start from the sides of Debian that people encounter, and usually when people meet Debian for the first time, it's about the technical project. So we are a project building a very successful distribution with a real impact of the world. That's really great because when you can go basically anywhere on earth and meet people using Debian or using Debian derivatives, we know about Debian, and if you try to wear Debian t-shirts every day and you will see that many people recognize Debian, that's really cool. I guess. Yeah, maybe you're in space, too, that's true. But it's harder to meet people in space. But then there's also the philosophical and political project about promoting and defending free software. And what's really cool about Debian is that we do that, but we really check about technical parts. It works like a feedback cycle between the technical part and the philosophical part. And we are not doing politics in the blind, we are doing politics while making sure that what we propose actually works. And then there's a social experiment with thousands of volunteer contributors all over the world. And Debian is really, well, building this community is a key outcome of Debian. And I really think that this place is a fantastic place to have a successful Debian that will help build the Debian community. So I try to find a symbol better than a group photo to describe that international community of contributors. And I came up with power plugs because I think that really shows the diversity of Debian. So the question I get asked quite often as a project leader is, how is Debian doing? And I think that most of the project is working fine. I decided to single out one team because usually it's a team that gets a lot of blame. It's an FTP master's team. And actually, probably most of you know that new processing had some small issues during the last few weeks. But if you look at the data, at the art data, there are seven members of FTP masters that were doing new processing since the beginning of July. I don't know if we probably, that might be one of the most active team in terms of active Debian developers. Seven looks like huge, probably the Debian team might have more, but still. And since the beginning of August, they processed 284 packages, like 11 days, versus only 73 uploads in the queue, new uploads in the queue. So we released with the, finally. It's quite obvious that this cycle was a bit painful compared to the previous cycles. If you look at the length of the cycle, we are a bit above our recent previous cycles. And the freeze was quite long. So we started the development of Jesse with the usual bump of RC bugs. And Jesse will be a quite challenging cycle. We really need to work on returning to shorter freeze because long freeze are really not healthy for the project. And we have some difficult decisions to take. First one about init systems. And also I think that during this cycle, well, at the beginning of this cycle, there are many architectures where the status is not completely clean. Probably we need to have quite difficult discussions about some architectures. So I think that we should be really careful in making these decisions the Debian way, that is make sure that we take the best technical decisions. But once the decision will be taken, I think we really need to stand behind that decision as a project. And we should not let ourselves be divided by the decision. So Debian is almost 20 years old, but actually that's an age where most people stop growing. But Debian is still changing quite a lot. If you went to sleep in 2005 and wake up now, probably, the Debian project will look very different. I don't know if you know that movie about someone getting into coma and then waking up after the Berlin Wall was broken down, but it would be fun to have someone waking up now after eight years. So first, team maintenance, most, well, a majority of packages in Debian are maintained by teams now. Since about 2012, so the red line is packages maintained by teams, the green line is package not maintained, and the others are one, two, three, etc. So team maintenance is really the new way to maintain stuff in Debian, but then we have a problem. We have teams that get MIA. We used to have developers that go MIA. Now we have teams that go MIA. And actually, we are not quite good at detecting that. When I did the survey about new contributors, one of them had a nice story, well, not so nice actually, they created a team with only one DD to maintain a set of packages. And then the DD went MIA. And the team was still active, but with no one to talk to to upload the packages. So it's kind of a lonely island in the middle of Debian. And we are really stuck at detecting that currently. We need to work on that. Something else is the use of VCSEs that's related to teams actually to maintain packages in Debian. So the green line there is Git. The red line there is No VCSEs. And the blue line is SVN. So Git is clearly taking over. All of those solutions, well, DAX is increasing, I'm not sure why, well, probably some teams that ask a team maybe, but Git is really the new standard to maintain packages. Which way, well, we have several ways to maintain packages using Git. Each team tends to develop its own workflow with its own procedures. And that really sucks, because as a project we really need to standardize on a single way to maintain packages and not have the project divided into smaller projects with each its own way to maintain packages. So there's really some work to do in that area about it would be fantastic if some teams use Debian Conf to come together and decide on a standard way to maintain Git packages using Git. And then there's also packaging helpers. So the blue line is DH, the red line is 3DH developer, and the green line is CDBS. Because that graph is always quite funny because DH was originally advertised as a CDBS killer and actually it's not really killing CDBS, more like killing a developer. But still, that raises a question. What do we do about our former way to maintain packages? We are quite slow in general at deprecating the previous standard way to maintain packages. Usually DH knows the new standard, but packages are only slowly becoming migrating to DH. Oh by the way, if you were wondering, those kind of staircase, steps there and there, those are the freezes. So you can see that things slow, slow down during freezes and then start up again, which is expected. So Debian is almost 20 years old, so first I thought that a clarification was needed as computer geeks, it's in decimal. And when you see that, you can ask yourself another question, which is what should we do before reaching 20 in X. Actually I'm turning 20 in X this year, so that's something I gave some thought. Or maybe, oops, oh, okay. That's the problem with making less than changes to presentations, it's okay. Or maybe what should we do before, well, during the next few years, what are the big challenges? So first, if you look at the global picture around Debian, we have upstream projects, we have users, and Debian is in the middle. We get software from upstream projects and we turn them into packages that distribute to users. Second, we get feedback and bugs and sometimes patches from users. And we forward them to upstream projects, or we sometimes forward them to upstream projects possibly with adding patches. But that's not the only thing, we also have Debian derivatives for which we have the same schema. And some of them also have their own derivatives. And so that's really the picture of how it should be, with Debian really at the center of the free software ecosystem. But some of those streams don't work so well in some cases. So one can ask whether we are always a good downstream for upstream and a good upstream for our derivatives. And I think there's room for improvement. In some cases, the relationship we have with downstreams or upstreams is really good. But in some cases, we can do better in that area and really reinforce the position of Debian in the center of the ecosystem. So there are simple things you can do. First, contact your upstreams. When you start maintaining something, it's really important that you talk to your upstream if you have an upstream. So talk to them, ask them to review your plans. If you plan to package a new upstream version, it's good to send them an email beforehand so that they can comment on whether you should do that or just wait for the next release or something like that. Provide them with feedback and bug reports. We have something that's not very well known. It's patchschwacker.debian.org that extract patches from Debian packages so that upstream can easily integrate them. Ask them to subscribe to the packages on the BTS. So I know of a few packages, for example, coreutils, where the upstream maintainers are actually replying to bugs in the Debian bug tracking system. And that's just great because users report bugs in Debian, the upstream maintainer comments on the bug directly in the BTS. It's the perfect way to work. Not all upstreams want to work that way, but when they get to work that way, it's just fantastic. Look at your downstreams, our downstreams are bugs and patches. And there's a panel tomorrow at Debian about derivatives, it would be a good idea. We had a large audience attending. But more generally, I think that we need to keep in mind that Debian is also about improving free software as a whole and we should not work, well, we should work on improving Debian, but we should really keep the global picture of improving free software and improving the world generally. And for that, we need to be a good player and collaborate with all entities. So then the ecosystem around us is changing. Everybody is talking about cloud, which is a nice buzzword, but not only a buzzword. And it brings virtualization and elasticity of infrastructure and software. And our model where you install a system once and then you upgrade it for 10 years using several Debian release, it becomes less relevant with that ecosystem because you just start up a new virtual machine, you don't need to upgrade Debian that often anymore. And that raises many challenges for Debian. First, the cloud, as pointed by many people, is taking freedom away from users. So we need to work towards preserving that freedom and we have several ways to do that. For example, we can package software so that users can deploy their own private cloud. So we are doing that. There are some improvements there. These are really, really hard software stacks, usually split in many different packages with custom configuration of services. And well, more manpower on that part would be really nice. Then we also should work on packaging PaaStacks and SaaS stacks, standardizing platform, development platform, deployment platform. And having the standard platform in Debian is really important. So for SaaS, actually we run into the usual problem of web applications packaging. That's not something we are particularly strong at. And it's increasingly important. But then on a more technical level, the world is using Perpetual Chef everywhere or is trying to use Perpetual Chef everywhere. And one can wonder what's the role of Debian packages, package managers, and of configuration using DebConf in that world. And we might need to evaluate what we do and maybe adapt a bit so that we can better integrate with those tools. And for public clouds, that's also the question of official Debian images. What does it mean to provide Debian on a public cloud such as Google's or Amazon's clouds? So if you look at this year's DebConf schedule, there are eight cloud-related sessions at DebConf. And I hope that we can address or work on all those topics. So probably something that will raise some discussions. I think we should look into meeting all our users' needs. So we have Debian testing, which is the first and the best rolling distribution. And I think we should really acknowledge that and advertise testing as such, as the rolling distributions. So testing is already widely used. During the last few days, I made some stats from Debian Mirror. And actually, if you look at the HTTP logs from that mirror, you see that... So what I did was take the log, grab for people fetching the packages file, and then look at which IP fetches which packages file. And 42% of the users of that mirror fetched the squeeze packages file, 60% the withy one, 12% the testing one, and 11% the unstable one. So it's not, well, clearly there are more users, well, there are two possibilities. Either we have very few users and many developers, or we have quite a lot of users using testing and or unstable. If you look at the popularity contest submitter, so this doesn't add up to 100 because one specific IP can fetch several packages file. If you look at popularity contest submitters, so looking at the version of the popularity contest package that is used to submit the results, we have about 10% of people using testing or unstable. So and actually that share, so that's the blue share there. It varies quite a lot during cycles and at the end of the withy cycle, just before the release, it was a lot more people using testing or unstable. So that's not something new. We have people, lots of people using testing and unstable. But there are also many other good reasons to go into the direction of the rolling release. First it makes us provide more recent software to users. So for the free software community in general, it means that we build a shorter feedback loop between upstream projects and the user. User can use recent software, report bug on recent software because usually when you are an upstream developer, you don't really care about bugs in software you developed two years ago. Probably the bug was found in the meantime. The more people we have using recent software, the more bugs are fixed and the more in general free software is improved. It gets us more testers of the next table release. So usually what happens, well, it's quite useful from a release management point of view to detect bugs earlier. It gives us more time to fix bugs. And actually, if you look at Christian stats about bug reporting rate, the Ubuntu bug reporting rate is much higher than Debian which is a bit roaring. Of course, if you are, I don't know, ice with a maintainer, you don't really care about receiving more bugs. Probably you have enough and it's pretty well covered. But if you maintain quite obscure Ruby library, it could help to have two times more users because probably if you have only 100 users worldwide, not all of them will report bugs. It could be helpful to increase that number of users. Something else that it makes us attract different users. So if you look at people using Arc Linux, for example, most of them are quite young, enthusiastic Linux users. And attracting more of these kind of users to Debian means that in the end, some of them will turn into Debian contributors. And having the image of the old and boring distribution, which is not completely true, but some of it doesn't really help us recruit new people. It's better to be, well, we can stay with the old and boring aspect, but it's better to have the other side of being young and really active. And also, I think that actually it's low-hanging food because there's no need to change anything. It's mainly about PR, about communication, communicating to the public that testing is usable as a rolling distribution and, well, just use it and stuff like that. So I think everything is there, just need to advertise it. Of course, the big challenge with that is to coexist with the stable release and to not arm the stable release. We really need to work on, well, we should be really careful about not decreasing the quality and the workforce that goes into our stable release. So about manpower, the challenge for the next few years as usual is to, as it was for the next, for the past 20 years probably, is to recruit new contributors. So everybody complains about manpower, this is a regular complaint and I think it's a justified complaint. There are many areas in Debian where we could use a lot more manpower. As a DPL, I often have to poke people about why it's something not working as expected. And, well, of course, it's easy to blame the lack of manpower but sometimes when you don't have, well, sometimes just boys don't do that and you can't do anything besides that. So I made a survey of new contributors, you might have read the report on the Debian project last week. What it shows is that it's really hard to contribute to Debian. As a project, we tend to build very efficient processes and tools so we like to be, to optimize stuff for ourselves but as a result, those processes and tools are often quite complex and difficult to learn for newcomers. And, well, that's a trade-off, well, we tend to be selfish about our processes and tools and, well, it's hard to change but keeping that in mind when designing processes and tools would be, still, already be a good thing. We have very high quality requirements. The attention to detail we put into our packages, it's just incredible. Of course, that's something that contributes greatly to the success of Debian but, still, for new contributors, it might be a bit surprising. We have a misalignment between our contributors' goals and our goals. What we want, really, is people who just join our teams and fix all the teams' bugs and upgrade our packages to the new version. That would be fantastic. Well, I miss people come with an idea of what they want to do inside Debian and, usually, it's package this thing I use that, well, maybe nobody else uses but that's something that is important to the new contributor. And, well, we need to find the middle ground between what the new contributor wants and what we want. And, also, one thing that the survey showed that it's very hard to get sponsored outside of the team. So, if you want to package something and there's a team where it fits, it's fine. You will probably find someone willing to sponsor your software. If it doesn't fit in a team and you don't know, you don't have a friend or colleague with a Debian developer and we will do the sponsoring for you, then it's really, really hard. So, you can all help change that. I think it's a really collective responsibility to change that. First, subscribe to Debian Mentors and do some sponsoring on Debian Mentors. If all of us do one sponsor on Debian Mentors per month, I think the problem is solved, basically. Problem is, if you look at the Debian Mentors archives, last month, I think there was like four or five different DDs doing reviews and sponsoring. So we cannot point to something where only four or five different DDs are active. And something that is, well, deep in the culture of Debian is that you cannot make mistakes. And you're not allowed to make mistakes. And I think that for sponsoring, it's really hard because you are asked to review something and you cannot read all the F-stream code or you cannot audit all the F-stream code looking for possible bugs. At some point, you take the risk to make the upload. And sometimes it's true that mistakes will happen. And I think we need to be better at accepting mistakes. It's okay to not know everything. It's okay to not be perfect right from the start. But it's better to be vocal about things you don't know and things where you are unsure than to just hide it under the carpet and hope that nobody will notice. And actually, even reviewing packages is something quite hard because, well, if you miss something, everybody will see it. But I think that's okay. We should really increase the culture of this being okay. One of the, someone mentioned that one of the people doing reviews on Debian mentors, there's a lot of reviews but never sponsors. So I'm not sure if it's because they feel that they are going to make a mistake by uploading something that, by missing something in the reviews. But that's really sad. I mean, we need to, it's okay if you make mistakes from time to time. It's software, you can probably revert it somehow. It's really hard to break Debian badly by sponsoring something. So there's some work to do on infrastructure around sponsoring. Mentors at Debian.net got rewritten two years ago, I think. Well, the current version got the work started two years ago using a summer of code project, I think. And it really helps, but there's more to do. For example, in many cases, the review is just, oh, you forgot that LinkedIn error. If we had automated LinkedIn checks of packages uploaded to mentors, probably the user, the prospective contributor will notice and there's, well, this limits the need for reviews. So I think that, well, Nicolas Dandrimon mentioned that work is underway there, I think it's Paul Tagliamonti who's working on that. So something else is related to the misalignment between contributors' goals and our goals. We need to be better at advertising tasks that are suitable for new contributors. So if we don't want new contributors to package, well, another image viewer, we need to provide them with ideas of things they could do. So we have WNPP Alert. Who in the room is running WNPP Alert on a regular basis? One person, congratulations. So we need a way to make it easier to discover opportunities of contributions. There are lots of opportunities for contributions, actually. If you run WNPP Alert, you probably find two or three packages that you rely on that are often, and if you find someone to adopt it, I mean, it solves your problem for those packages. We need to design better and simpler processes and tools and document them. But for example, everything related to using IOS, using Git, using SVN to maintain packages, this is quite poorly documented currently. So something that's really, really, as was mentioned, that's something really useful is everything related to peer mentoring and internship projects. New contributors really liked human contact of having someone to ask questions to. That's something that I don't know exactly how we can improve that yet, but that's something, well, Andrea still has some ideas, there's a session about that, about peer mentoring. But yeah, we need to work on that. But well, in general, basically what we need to do is help Debian become a more welcoming project where people can start contributing more easily, because currently it's really, really hard. So if you look at the schedule, there are seven events related to that. So the good news is that people care about this. We just need to make progress on that. And then before I conclude my talk, I want to talk a bit about Debian governance. So I just learned a new job. My vision of the new job is that many DPL tasks are quite short tasks, where if you do them with low latency, as soon as you receive it, it's done, it's much better. So for example, everything related to money handling, email redirection to the right people, poking people about something, everything related to legal, there are some constraints about how long you take to answer. And all those tasks are quite hard to delegate or to share, because there's a hard coordination override. If you want to share them with a team, it doesn't really work, because you will spend a lot of time coordinating with the rest of the team and it doesn't really make sense, so you can do it yourself. But there are also lots of tasks that can be delegated either totally or partially. Even writing a delegation, for example, that's something that takes some time, because you need to contact the team, figure out who they would like to see added to the team. Then you wait two weeks because nobody noticed your mail and pipping them again. That's quite time consuming. And actually, there's only the final act of sending the delegation email that can only be done by the DPL currently. Everything else can be prepared by someone else. And that kind of thing would be really useful. So, Zach started the DPL Helpers Initiative in order to try to distribute those tasks to a team and to teach more people what DPL tasks are about. So, my view for that is that it could be a kind of government for the Debian project. It is you have someone that is mainly responsible in doing that kind of short tasks, but then you have a group of people each with their own area of interest doing specific things. For example, we could have someone specializing in all legal stuff, in all new contributors related stuff. And these are areas that are quite easy to define and quite easy to delegate. We delegate in the informal sense of the way. This doesn't really need to be something official for most of the tasks. So, the problem with DPL Helpers is that it's not very active. We had only two participants at the last meeting. So, I feel a bit trapped as a DPL because I was hoping to rely on this to share the load. Actually, there's not so many people willing to share the load with me. But I wonder whether this could be the basis for a more sustainable governance model for Debian. Some things that could work and that would allow someone not from French academia or not self-employed to be the DPL. Because we're running out of people from French academia. So, there's a both about that. We might mention things going on currently, active tasks. But I also would like to spend a lot of time discussing this and how we can move forward and make it possible to move away from French academia. Okay, so that's the end of my talk. So, thank you for coming to Debian. Enjoy Debian. I hope it will be a very successful Debian. I'm quite sure it will be. Please use Debian to come and talk to me in person. So, that's my leader email which is archived and my arsenic name if you want to ping me and then we can meet somewhere. So, that's a kind of reminder of what I talked about in my talk so that you don't need to ask questions about only the last points or only about rolling. Thank you. About the rolling distribution thing, the testing and rolling distribution, I see a potential problem that has already been discussed and I already raised it in IRCs. When the freeze comes, would it be, this rolling distribution, would it be freeze? I mean, would it be intermittently rolling? Would it be handled differently or there might be two overlapping testing distributions at the time? How might that be handled? Well, I think that with that freeze duration, it's probably a big problem. Well, with that freeze duration, I think that we can live with everything being frozen for three months. Almost four months. So, I think that everybody wants shorter freeze. That would be useful for rolling distribution. So, let's just aim for shorter freeze and let's not try to do something more complex that might hurt stable releases. At least for now, maybe in five years from now, we'll figure out something that makes everybody happy. But what we do currently, I think, is fine. I don't think three months is an acceptable freeze interval. I really don't. I mean, we've had this conversation at the last several web comps, and I think a really good target duration for a freeze is two or three weeks. If we can't run a process that allows us to return unstable to being unstable in much less than a month, then I think it really negatively impacts the ability of lots of things in the project to keep rolling. Those stair steps that show up in many of our plots are just, you know, very frustrating. Yeah, but it also depends on what you call freeze, actually. Well, our definition of freeze, if we change the definition of freeze, we can have shorter freeze. Short of total freeze, for example. But I mean, there are things to explore in that area, like making sure that key packages don't get upgraded to new upstream versions just before the freeze. Yes, yes. Obviously, this is all part of what it takes to make something like that happen. I'm certainly not advocating a return to the very, very old process of let's just grab a snapshot of unstable on a particular day and call it a release. But there has to be something in between because when we end up in a situation where for many, many months we're not changing, you know, tool chains and core libraries and so forth, it's very, very easy for people to lose focus, you know, for their attention to move elsewhere. And then I think it's very hard for us to get it back. I clearly remember the talk of Anthony Towns in 2001. It's his first depth prompt when he introduced pool system where testing was introduced. And somebody else and me raised immediately their hand. What will happen with packages who are in testing and have a release critical bug? Will they removed again? And the decision was no. But I think there is some tendency now to remove these packages, at least leave packages, which have released critical bugs. And I think this is quite a good thing. Yeah. I think that we should go further in that direction. That is, well, we tend to treat all packages as equal, which is nice because our users rely on all of our packages. But some of them are still more important than others. And if we had a way to easily detect which are the bugs that really need to be fixed before the release and which are the ones that, well, we could just remove the package if it doesn't work. Okay, some users will suffer, of course, but it doesn't block the release. It would be a good way. But maybe we should just go further than removing packages during the freeze, but also remove packages now. I mean, if something is clearly unsuitable for the next release, we could just remove it from testing now. And if it gets fixed, it can get back. We have at least, well, almost two years to get back in testing. So get it back in shape. But, well, almost, well, we have very few release team members present at the conf, which is a bit difficult to discuss that. And that's the main responsibility to decide that. Of course, I need to talk with the project, but it's very hard to decide about that. So, Luca, you make two proposals. One is to make testing more a rolling release, and the other is to remove more things from it. How do you reconcile those two? I'm quite sure we can find technical solutions to that. And there are already technical solutions such that people just install packages from unstable from time to time. And for the users that we are targeting anyway, it's not really a problem if from time to time they need to take specific. Actually, if the package is not in testing and you have unstable in your source.list, it just works. But I don't think our main problem are leaf packages are there. I mean, you can always say, like, if there's a bug in a library, then let's remove it. So if there's a bug in LibRuby, let's remove Ruby and all its packages. I mean, leaf packages are not our problem. To remove leaf packages is easy. And we do that. Question is what if there's a bug in Ice Weasel? Yeah, but I think bugs in Ruby, but maybe I'm a bit biased about that. But Antonio can eat you if it's just next to you. But I think bugs in Ruby are probably the kind of bugs that should be fixed. Because, well, we need to draw the line somewhere, of course. But Ruby is probably on the let's fix it side of the line. I'm not sure that, I don't know. Well, some obscure Ruby library, like Ruby FitPaster, I'm the upstream for that. Nobody cares if it's getting removed. Well, some people will care. So I'd like to propose a radical answer to that question, which is that we should be prepared to revert something like Ruby to the previous upstream version if it fixes release critical regressions. And obviously that should be done with some care, but it might need to be done as an NMU. So we need to develop some collective understanding of when that might be appropriate and how to manage the fallout. But if we're able to do that, then we'll be in a much better position to fix bugs that are somehow intractable just by undoing the problematic upload effectively. But I think this is already happening kind of during the free. Sometimes it happens that we just revert something to the previous version because it's a new version to these problems. Often it's because the maintainer decided to update and it was not really a good idea, but we already have that possibility and use it from time to time. I'm not sure it really helps fixing, it would help fix that many additional bugs to develop that better. One thing that is related is the kind of having a feature branch for packages and having a way to revert specific changes. Currently we only have one development branch. We could have a feature branch where every package, every new version of a package leaves or sets of packages leave and have them merge into unstable or testing something like that. That's a lot of technical development. Okay, I think time is over. If you want to discuss this further, you have to use the hallway track. Thank you.