 Next up is Mehdi Dugi, who is current DPL. He's going to share some bits from the DPL. Hello, so my name is Mehdi. I'm pretending to be the DPL for the next year. And I'm here to talk to you about what's going on in Debian. So welcome to everybody. I'm glad to be here. I'm glad to see you all here. So thanks for the 16 team. I know how the work has been frustrating. And the energy they put in. Thanks for them for scattering my talk during, I mean, just after the cheese and wine party, so that everyone is ready for the talk. And thanks for the University of Cape Town for hosting us. So, some funny facts about this conference. It's the first time it's organized in Africa. It's really important for us to reach out to new users, new communities, new people. So it's very important to Debian to change the country every year and continent. So we're doing also a conference about Linux. It's the first time we're having a conference near Bingwens. So that was important enough to say it. It's also the first time we have a DPL born in Africa. And we can keep going, combining those funny facts. So the last one was important for me because it shows how our community is diverse. And we want to, I mean, we like it like that, right? And we have to keep it that way. So how is Debian growing these days? Some changes in some teams. So there were delegations of Debian maintainers, curing maintainers, and front desk delegations which were revoked. The basis for that was that the work didn't need any delegation, any special power to be delegated. Their work was mainly administrative. So the delegation was not needed. The one who needed delegation was Debian account managers, which are still there. It doesn't mean that those teams will disappear. They don't need any delegation anymore. So everyone is, I mean, it's easier now to help them to get the work done. And it's very important to get it done because it's our way to get new members into the community. Other important stuff, press publicity and bits teams were combined. Now we have only one team working on those subjects. So taking care about press releases, publicity work, and all the communication that happens in the bits blog. Also, we have the anti-arrestment team that we didn't maybe make big promotion around it in the past. But it's somehow very important in our organization to make sure that everything keeps going well. And we have Laura and Neil who volunteered to join the team recently. So they joined Marga and Patty who were already in the team. So thanks for Neil, thanks for Laura. It's not very visible work, but it's very useful for our community. And to make sure that some teams don't get inactive, I'll make regular teams of selected teams to make sure there is someone replying to the questions during the work. So some numbers about what we've been doing lately. I don't know if you've noticed, but there is only ten packages in the new queue. The FTP team has been doing tremendous work on that and they deserve a big thank you and big applause. I mean, I think many people didn't expect that and maybe didn't see that in years. And it's good to see it happening again. It's very important to have people active in the FTP team and the new queue is something that it's just kind of last step. So we are doing all the work and now before publishing it, it's held in the new queue until the review by the legal staff on the licensing. And so it's awesome to just have only ten packages. We also have 90% of packages which builds in a reproducible way in testing on IMD64. So given the age of the project for reproducible builds, it's like awesome work. I mean, there are many people working in that and they have awesome results. So they also deserve a big applause because it's tremendous. So we are also welcoming 29 interns this year, four from Outroochie and 25 from the Google Summer of Code. It also shows the interest of people in our projects and the work that could be done. And so welcome if there are any in the room or watching us on other streams. Also about Jesse, we've had the shortest freeze, so only 171 days. So we wanted shorter, but yeah, it's still kind of short. It's like six months or something. And we, I mean, the release team is trying to make it even shorter for the next release. And it's counting on all of you to have a look at your bugs and getting things fixed in time so that we can enjoy developing things even more for Boston. Yeah. So all those show how what is going on in Debian. And one question I wanted to think about is what made Debian successful, actually. So I try to summarize it in four points. The first one for me is the large active community. The work is done by the community and only by volunteers. And so all of that is thanks to them or us. Second thing is about the quality and stability. That's something that is well known for Debian and people are organizing it. Also the largest package repository. It's one big selling point for Debian actually. Ryan Ryan that to make to not be a to be enforced to compile things by themselves and having things integrated in more one large repository. And the fourth point and maybe the more important, most important one is our complete commitment to free software and the philosophy of our project is documented in some in the DFSG and Debian social contract. And it also in our way in doing things. We were heavily on volunteers and only and sorry. And it's important to keep it that way. So if you want Debian to be still relevant and successful in the future, we have to make sure that those points still hold in the future. So I'm going to speak about the first three. But the community and the package archive. And my outline for this talk will be talking about the code of conduct, the equity assurance, some proposal for roadmap. Trying to gather ideas for how to fund new Debian projects. And finally, I thought it would be useful to talk to you about the DPR workload. We had only one candidate last year. And I hope to see more candidates in the future. It's an important role in Debian. Past DPLs showed that many things can be made possible with DPL support and commitment. So it's very important to have more people interested in that role in Debian. So the code of conduct. It's a document which clarifies our values and principles. It can be summarized in five points, very simple. So it's by being respectful, having good faith, being collaborative, trying to be concise and being open. Maybe the most complicated one is being concise. We like details, so writing long mails is something we know how to do. And another important document is the Debian community guidelines which were written by Enrico a few years ago. I don't know if some people heard about it in the past. So by the way, who did read the code of conduct? Okay, that's still not 100%. And we have to fix that some way. So first, if you have any issues, you have to talk about it. Talk to the harassment team, approach the Debian account managers, talk to people next to you, go to the front desk or get me, whatever. But be sure that someone listens to you. We want to provide a safe environment for our contributors. People are coming nowadays with their friends, with their family, with their children. So it's very important to make sure that the environment is safe and people are still having fun. So we have some procedures to get things secured in some way. So we seem to be doing fine at that point. But there are still ways to enhance the situation. So first, I think that we should make consequences of misconduct more explicit in the code of conduct. It's kind of blurry of what you risk if you are misbehaving. Like for example, give some explicit examples. What do you risk? It's very important to say that if you're misbehaving seriously over time, you risk to get your account locked and getting out of the project. It's not only about being banned from mailing lists, because for now the code of conduct says you will not be able to use the Debian communication systems, but it should be more explicit. Also, the amount of its existence, some people didn't read it. I mean, that's fine, but we have to fix it. You have to read it, and we have to communicate around the code of conduct. Also, so nowadays the code of conduct can be seen as some of our core documents, which defines our community, our project. So new members, when they apply to have a DD account or a DM account, can sign up for the code of conduct just like other documents like DFSG and DMAP and social contract. And it's something that is very easy to do, and that way we make sure that people are aware of its existence and its content. So we should be doing that. So now about creative assurance. So we've been packaging stuff over time. The archive keeps growing and growing. We're adding thousands of packages for each release, so it's getting immense. And we used to rely on unstable users to get the archive tested and have you rely on them to report RC bags and make sure that RC baggy packages don't migrate to testing. But with this size of archive, manual testing is less relevant than it used to be. And we have to find new ways to make sure that the archive is still of a good quality. So fortunately, as we are some paranoid nerds about QA, I guess, we have many tools. So we have Pupers, Jenkins, Doze, CI and other tools like we are doing reproducible builds. We have Lintian and those are great, but they have to be integrated in some way. So CI appeared a few years ago and we already have 20% of packages covered by tests. But those are not, I mean the effect of the tests being passed or failing don't affect the archive for now. We have other tools like the auto removals. I don't know how many of you realize how the auto removals enhance the situation with respect to the number of RC bags, but it's kind of huge. It wasn't introduced there. So we see the drop of packages, I mean RC bags, which is, so the green line is for the next table release. So it's for testing. And it's when it was introduced, half of them, half of the RC bags were just like removed from testing. It's not about hiding problems, but at least buggy packages are not in testing anymore. And this helped quite a lot for just the release because when we started, we didn't start at like 1,000 RC bags. We started with quite low number of RC bags. So we've done some archival build here and then got the thing, got, I mean, the archive fixed. So nowadays we have the bug tracking system at the heart of our workflow. Some tools on the left side file new bags into the system, mainly manually today, but it could be automated in the future. Some tools are relying of what the bug tracking system has to make sure that the archive is not buggy. So we have the auto removals. We have also the Brittany program, which produces the testing suite. So we can imagine that in the future, CI tests could prevent packages from migrating to testing, if there are regressions or even if the test suite is failing. There are probably more things to do. So it's up to you to look for new ways to test the quality of the archive. And that's it. The roadmap. So that's another subject I wanted to tell you about. There is no doubt about the size of the project. It's quite big. There are many teams and it's hard to keep up with what happens in Debian. Also communication is not our strength. We don't, all of them, all of us don't write blog posts about what we do, about what we are planning to do. So it's hard to, every contributor to know what other people are working on. It's even harder for our dance streams, which rely on what we produce. And also for users and non-regular contributors. So we should find ways to promote our work and get it understood by our users. And this is not the way to promote our work. It's a nice way to see what happens in the archive when it doesn't fail. But otherwise it's not very efficient. So in the past we used to have the release goals, which kind of promoted the plans we had for the project. They were meant for the next release. We're not release blockers. And their severity was too important to let people do NMUs in a timely manner. The thing is they were bound to the next release. So as we are relying on volunteer work, it's not always easy to commit on a deadline, which can be considered kind of short of one year and a half. And the release team at some point decided, rightfully, that they were not the good body in Debian to decide on what should be a goal for Debian or what should not be a goal for Debian. So they were dropped. And they have the announcement there. But we can be what we consider, right? We have to document what we want to do in the future and what we want to enhance in the project. There are many things to do, but people from outside the project are not aware of them, even people within the project are not aware of all the things that could be enhanced. So we have to promote that. So a roadmap or call it like project goals or whatever, just some way to reveal the gap between what we are now and where we should be doing, what we should be like in the future. It's a way to set priorities. Like something in the roadmap has more priority than something that is not. We also lack a way to set a vision for the project so that people know where we are heading, what we are doing, why. And it can be seen as a recruitment platform. I don't know if you've thought about that, but each time I try to recruit new contributors, often they reply to me, but I'm not interested in packaging. But Debian is not only about packaging. There are many ways to contribute to Debian. And maybe with the roadmap, when they will see the, for example, application porting efforts that it would be doing, or application converted to new systems or whatever, they will be motivated to get things done because there will be like some kind of to-do list, and it will be easier to understand where they can hang on the system. So it's also a way to motivate people. When you're many on a goal, it's better than when you're isolated. And sometimes we don't realize that we are working all on the same goal. So that's a way to get the bigger picture of the project and get people focused on some goals. We could be doing that with smart criteria. It used to be smart, but I dropped to DT explicitly because we know how to do those. We know how to specify a specific goal. We know how to measure some goals if they are specific. We know, I mean, we kind of find volunteers for that work usually. And we have to make sure that those goals are realistic and relevant. So the roadmap should be flexible. If something is not relevant anymore, we should be able to drop it from the list. And if it's not realistic, maybe it's premature to add it to the list yet and kept for the future. So the T was for the time. Goals should be timely. We should set a deadline, but we can have troubles committing to a deadline. So we can say for some, okay, it's ready when it's ready. I cannot commit to a deadline, but somehow, someone, it will be ready. What we can do also is to say, okay, it will be ready in the next two releases. Just not now because it's big work, not the next release, but the one after. And that's something which sets some deadline in the future, which is still realistic. So what the problem is not. So it's not about the release goals because goals shouldn't be necessarily bound to release. They should look after, I mean, unplanned for the future. It's not a way to discourage individual initiative. It's actually quite the contrary. It's to be sure that everyone's work gets the visibility that it deserves. And by putting them in the roadmap, you make sure also that you have ways to attract new contributors. And it's not only about packaging work. There are other things that we can do in the project. Like for example, we could have goals on our infrastructure. Many things can be done there. I'm sure DSA has a lot of ideas. I'm sure that everyone who is maintaining a service has ideas for that. And we should have ways to promote that work and get it more visible. So who can organize that? One way it could be to say nobody because no one volunteers for the work and it's kind of big work. We could say that it will be the DPL but I think it won't be sustainable and it's not maybe the best place to do it. It could be the technical committee because it is meant to give advice to developers and give some, how do you say, it's like an advisory board. So you go to see them when you need advice and the roadmap is exactly for that. You have ideas, you want to promote them and you want to make on other projects in Debian. And it could be the body that ensures that all the vision is coherent. Constitutionally, it's also a body that is renewed every few years. So we can make sure that it's not only a few sets of persons that are defining what the project should be doing, which is important for me. Or we can imagine a new team, even if we have many, many teams. My preferred solution is the third one obviously, but that's something that should be discussed with the project. People should agree on it and the technical committee should agree on it before doing it. Then what we can imagine as goals. So I've listed some ideas I found on mailing lists. Some people say that for reproducible builds, okay, it's big work, but we can focus on the base system at the first step. So get sure that essentially yes and required packages are reproducible. Or maybe I heard yesterday that the first CD for installation could be made reproducible at least. We could get all diamonds provided, I mean package with them and providing system defiles, moving from the menu system to desktop files or CI blockers for testing migration. And I'm sure there are many other ideas. We can reuse the ideas that were published for the release goals for Jesse in the past, are the ones that we didn't manage to finish in time. So you will be asked for what you want to do in the project and it's very important that everyone contributes to the list. So the roadmap to summarize is a way to promote our work. Many people from outside the project don't get the big picture and it's a way to tell them what we're working on. It's a way to share a common vision, goals on the project. And more importantly, we have to find a decision process to how to organize all that and work on them collectively, all together. And if you're interested, there is a buff organized on Thursday where we will be discussing that. So I hope everyone will join and to see you there. That's all about the roadmap. So now about funding Debian projects. We have some ways to spend the donated money. So we are organizing dev comps, I mean events in general. So dev comps and mini dev comps and sprints, etc. We are also buying hardware for developers to get things done like for example when you have a driver to test, it's a lot easier when you have the hardware for it accessible. We also spend money on some infrastructure, mainly the domains and certificates but also some servers. So that's how we actually spend the money which is donated today. We also have other initiatives to extend the security support for our archives. And there are companies who contribute by hiring Debian contributors to get the work done there. So what we can notice is that that's some work that's never been covered by volunteer work. And it was very nice. I mean I'm sure the security team appreciates the work that is done by ETS today because everyone uses it, companies are using it, users are using it. It allows them to keep their systems running for longer. But we have to detect other projects stuck and not done in Debian. And they could be funded or we could think about it, find new ways to get them done. And likewise there is a buff on Friday on that. So if you have ideas, if you've seen projects that don't get... I mean we, like we've spoken about like four years ago but nobody stepped up to do them. We could try to think about how to get them done. So every idea is welcome. So finally about the DPL work and I think I'm on time, right? So I'll be quick. How many requests do you think I get every week? Some number. 500, okay, a bit less. 10, well it's actually 10. That's only the request. So as you see here, you have to reply to mails and start some discussion about, I mean what it's requested. So it could be a bit more but it's not that massive. But what people think about when we are speaking about the DPL workload, we usually imagine thousands of mails and flamers and private stuff etc. But it's actually not the case. It's going well. How many of you did send a mail to a leader during the past 12 months for example? Not that many. There are a lot of requests here. So what's about the daily tasks? So you have the mails, you have to know, I mean you never know what people will ask you. So you have to be responsive and reactive. You have to watch your mail. You have to pay attention to teams that might need you. For example when we approach DeepConf, people might need to do some expenses. And you're usually the last step before the action. So if you don't reply in a timely manner, things get stuck. And it's important for you to be reactive on that. So there are some things about approving expenses and budgets. And the communication part. If you're doing things, you have to communicate about it. You have to be transparent. I wanted to summarize what it's still 10. Summarize what could make a big difference in the job a DPL can do. So it's about availability to reply to the requests and get them going forward. It's about transparency. If you're doing something, you should not hide it. Because it's very important to communicate on our stuff. It's also about communication. And I put here imagination. Because when you have something like that in the Constitution, you have to find ways to use it, right? And yeah. It's a way to introduce some innovation and change in the project. And that's actually what makes new things possible. That's actually the only power that a DPL can use to make the project doing new things and going forward. Yeah, and I've finished. Just to remind, so if you feel confident about those, please write a platform starting from now. Talk to people. Come talk to me and nominate yourself for next DPL elections. It's very important. And you should be considering it. And if you see people that you want to see, I mean if you know people that you want to see as DPLs, talk to them. Encourage them. It's very important to get them the feeling that they are needed and they could do good work on that. So thank you for your attention. If you have questions. We have a question from RSE. We have one quick question from RSE. Yeah, okay. He has been preparing his questions since yesterday. So he's going to ask it. So I'm going to read it with you because it's a long question. Regarding automated testing of Debian packages, do you believe only packages in Main should be tested or should packages in Contrib non-free be tested to? For example, at the moment only Main is tested by CR.debian.net, causing auto PKG test scripts and ZFS learnings to be skipped. Should we limit our testing to packages in Main to spend our focus and resources on DF-SG packages only? Okay. It's also related on how we build stuff. In the past we made sure that packages built for Main and non-free are built on separate builders so that we get the things broken at some point because we never know what non-free software contains. I'm sure we... I mean, if we are providing something to our users, we have to make sure that it's tested. Otherwise, there is no... It's not useful to do it. So he should be talking to Antonio and see how things could be organized. We have another RSE question, but let's get... You're already looking for your successor. Does it mean that you will not run again? No, I'm not looking for a successor. I'm looking for people to make the voting period more interesting and to foster... Yeah. And to foster the exchange that we could have during the campaign because that's a way to get new ideas expressed. And for Minions to help you, maybe? Sorry? And for Minions to help you? Well, also, yeah. If you are interested, yeah. And if you have ideas, importantly, get in touch. Then another quick question from RSE. What do you see as the biggest challenge for the Debian project? The biggest challenge? I think it's to maintain 50,000 packages and we should be thankful to all our contributors. Any other question? Or should I stop suffering? Okay, thanks a lot. Thank you.