 Welcome to bits from the DPL at DEBCONS 20 online. This talk is pre-recorded, but there will be a live session at the end of this talk for questions and comments. So a bit about myself, my name is Jonathan Carter and my Debian account name is JCC. I'm 38 years old, and the quickest way to summarize myself is as a free software hacker. I'm not a computer scientist, I just learn as much as I can in all directions and hack away at problems until I find solutions, and I enjoy doing so. I'm from Cape Town in South Africa, that's the most southern city in Africa, that makes me the second DPL to be born in Africa after Medi-Duki. So if you want to stay in touch you can contact me on IRC, where I'm known as High Voltage, follow me on the Fidivus, or if you'd like to know more about my work in Debian, you can visit my wiki page. And that's enough about me personally, so what exactly is it that a DPL actually does within the project? So externally, the DPL represents the project publicly. Talk about Debian at technical events and trade shows, bold and maintain relationships with external entities, and sets up contracts and handle legal matters. Due to COVID-19, giving talks at conferences have been limited but I've managed to give two talks at Debian events so far. First at Fikim Casa, who's a Debian, or stay-at-home news Debian, a month-long event by the Debian Brazil team, where they host a different talk each night. And at our first online mini-deb conf, I've also done two interviews recently. These slides will be made available at the end of this talk, where you'll be able to find links to all of these. Internally, the DPL listens to project members. Now, this sounds very passive, but it's actually a lot of work paying attention, getting to core issues, and keeping track of those in order to find solutions. This takes up a lot of time, and I've found video calls to be very useful for more complicated issues. In Debian, the DPL doesn't really have much power directly. The DPL isn't a dictator, but the DPL can assign power to teams. We call these delegations. The DPL also approve budgets and individual expenses, and works with the treasurer team on finances. This isn't an exhaustive list on functions that the DPL perform, so you can find out more information on these pages. I've also started a DPL blog recently, where I plan to post more frequent updates. And on to the topic of finances. Let's talk a bit about that. But before we do, for some context, let's watch a quick clip where Neil, a previous DPL, gives a recap on finances at Debian 16. Now, just a quick correction, the dates that he mentioned are actually intended to be from 2015 to 2016. Let's watch. Money. In my platform, I said we have too much money and we should spend it. Now, every request that came in, I replied and said, spend the money already. People said, can I have 2,000 euros for a sprint? I said, let's go up to 2,500 euros, because I don't want people coming back again and saying, oh, we went over the budget by 100 euros or so. Did a lot of work with Debian system administrators as well to get things like new disks, improved hardware, things like this. So this is just the money at SPI in the various earmarks that we have. And so, very pleased to say that with this great amount of spending that I authorised and told everyone to do, we ended up with more money than we started with the game. Oh dear. So Neil, if you found those numbers disturbing, you might want to watch something else for the next minute or so. Our money is handled by three different trusted organisations, namely Debian France, Debian Switzerland and Software in the Public Interest in the US. A quick note about those Debian earmarks, they cover Debian 14 to Debian 19. And although Debian generally results in some profit, these numbers don't reflect the amount of profit for Debian, since we often get Debian donations into our SPI account, but then spend it again via a local or another trusted organisation. Those Debian earmarks will likely be merged down to Debian by SPI's next reporting cycle. Combining data from their last reporting cycles, that totals to about US$896,000. But because these numbers are quite delayed, my estimate is that we're closer to about US$930,000 today. So, why is it so difficult for us to spend this money? Is there a problem? I don't think there's really any problem. On the incoming side, we asked for money for hardware and we're very happy to have basically gotten it twice. I think that supporters of the project have proven over and over again that if we ever do need money for something, they'll be there to help us. So, thanks again for all the support from our sponsors and donors. When it comes to hardware, it turns out that putting together a cohesive long-term hardware strategy for the project turns out to be a lot of work. This year, COVID-19 also got in the way with some supply chains and getting access to data centers. The good news is that the SA is procuring two new fancy Lenovo servers right now, which is a good chunk of money even after the good discount that we received from them. Of course, COVID-19 also got in our way of having meetings, including DEBCONF20. This is one area where we're actually usually good at spending money. Debian Knights also really don't like spending money for some reason. I've received feedback that some people just feel guilty to spend Debian money and will try to avoid it if at all possible. Sometimes it also feels like Debian developers are people who, for example, earn $50 per hour, but they'll spend five hours to save the project $10. That seems a bit carrot-intuitive for me and since we have enough money but are always short on time, I urge developers to flip that around and rather spend money where it could save time where possible and there's, of course, no need to feel guilty about doing that. Some improvements that's planned for finances is to make more use of delegations to draw up budgets and approve expenditures. Currently, that's how DEBCONF works. DEBCONF draws up one budget and then a DPL doesn't have to approve every line item that they spend money on, which makes it easier to spend and also decreases paperwork for everybody. So we'll have more teams where we do that. I also want to work with hardware manufacturers to get preferential pricing for Debian developers for new hardware. We got feedback from hardware manufacturers that they want better support on Debian for new hardware and at the same time we have some Debian developers who are really old hardware who can't really afford new ones. So I'm fine with the project spending money for them for new laptops but ideally I'd really want to see preferential pricing from any hardware manufacturer that wants that and more on that point a bit lighter. What I've also been doing as DPL, since I've been DPL, is to meet regularly with the Debian treasurer team and this week we also met with the SPI for the first time in that call and we're going to continue doing that with all TOs involved to improve our financial practices and there's lots of good ideas there. For example, we want to introduce line item reporting and do some coordination if we can do something like use the same category codes across all our TOs then that makes it real easy to combine these reports somewhat automatically and put together larger reports that give more details on what we spend money on and have better transparency for our project members with regards to that. Also the idea is that we show the world that we can and do spend our money well to make Debian better. I think one of the reasons why people like donating money to Debian is they know it will be put to good use and I think we need to show what we spend money on when we do to show them that we're actually spending this to make Debian better instead of just having money that sits in a bank account some way. Okay, on to some project stats. Thanks to the amazing efforts of many people involved and especially to the release team, Debian has gotten pretty good at releasing just about every two years. Since Squeeze we also had LTS which is why those bars have gotten more longer in recent years and there's also an extended long-term support commercial offering from Frixian that's not depicted in this graph of course. And in terms of our membership we have 1,015 current project members so that's the uploading and the non-uploading developers combined. The Debian Maintainer project is also quite successful. We currently have 215 DMs and if you're keeping an eye on the new maintenance list you'll see that they're receiving many new applications. That's a very good sign for the health of our community. I think this is happening in part because our processes for this have become so much better over the last few years and I'd like to especially thank Inhe Kuzini for his great work on this. On that note I'd also like to thank our MAA team for getting in touch with and tracking missing developers who may have either retired or have unfortunately become deceased so many thanks all around. So in an early Debian Conf there was a buff to discuss how we're going to have to scale up to be able to support 15,000 packages and then later on in this screenshot at Debian Conf 8 Steve was DPL and in his talk he said I had a quick look last night and I kind of scared myself. For I386 in Leni we are currently over 22,000 binary packages. Ow! So Steve if those numbers disturbed you I suggest you look away for a bit. So snapshot of Unstable I took recently had 61,071 binary packages for AMD64 and 31,723 source packages so it appears that we have roughly a ratio of 2 to 1 between binary and source packages. So how did we scale to be able to support 15,000 packages or even the four times as much that we have now? Well the answer to that is remarkably simple and that is that we just didn't. Sure some bottlenecks were pushed to the limits and fixed and some other things have improved. I mean at least we can do source only uploads now for packages already in the archive right? But I think AfterBulza is released we need to start asking some serious questions about 100,000 packages because that is a serious reality on the horizon and we should keep that in mind for everything from apps to our archives and mirrors to our bug tracker and any other process that might be affected by this. I think at Debian 21 there should probably be a session to talk about our future and what we can improve to be able to support 100,000 packages in the Debian archive. Before moving on from project status I'd like to come back to Steve's slide one more time. If you look closely on the last line of his slide he also talked about Debian developers getting married and sometimes even to each other. And on that note congratulations to Tammy and Voter who got married on the 29th of February this year. Tammy worked on most of the artwork for Debconf 16 and Voter was working on the sponsors loop for the video team at the time. They worked together on that and the rest is history. What made this wedding especially unique and almost surreal was how everyone at the wedding even the old people were really curious about Debian and kept on asking me about it. Now this is where I got pretty good at the question so what do you do at Debian? It's such a simple question but when strangers and especially non-technical strangers ask Custis we're completely stumped and providing an answer like oh I maintain a few dozen packages and fix some bugs for Debian live and also do some Debconf stuff etc etc. Wouldn't really mean much to them necessarily depending on what they know. At the same time if you say something like oh it's tough to do with computers it's not a very accurate or a helpful description because nearly every job these days has something to do with computers. So by the end of the wedding I got I got it refined to oh I'm a volunteer there and I'm also a project member which means that I get to vote on important issues. So that's a very short and also very accurate description that would be useful for people who actually know what Debian is and even if they only have a vague idea that could help them as well. So I thought I'd share that just in case you're ever at a Debian wedding and people keep asking you this as well. So following from the last slide I think that it's actually important that we start becoming good at talking about what Debian is and what we do inside the project because it's one of the two old problems that has been with us for a while. During the early stages of the lockdown year I started reading some old Debian developed threads and there was one thread in the late 90s where people who encouraged bring up Debian problems not even solutions just mention what I think is a problem in Debian. And what's encouraging is that most of the problems that were and big problems in Debian back then have actually been solved but these two issues listed on the screen and that is that we don't do enough marketing or get enough press recognition or that Debian is not as polished as other distributions or even other operating systems in terms of look and feel. These problems have come up over and over in various ways over the years even in many DPL talks I've only had screenshots of two of them there but there's been more. So I think we've actually gotten better at those but they're maybe not completely solved yet so we're lucky that our upstreams have gotten better at creating UIs that are more consistent and look better and are more pleasing and welcome for our users but I think we can still go a long way on building on our Wednesday and making it even better. I'm also glad that in terms of press at least internally we've improved drastically. I like the work that Laura and Donald is doing with the regular press updates whenever something happens in Debian. There's a news entry somewhere and it goes on all the social media channels and external press entities can pick up on that. That's really fantastic and I think bits from Debian is also really cool. It's usually just small snippets of things that happens in Debian and it's just fantastic and I think we should continue working on those and building on what we have there. So talking more about problems and even on a meta level I often say that Debian is basically a bottomless pit of problems. Now this isn't a negative reflection on you as a Debian developer or even on us as a project but it's pretty much inherent in the type of work that we do. If you consider the Debian GNU Linux system and the incredible scope that we take on we're affected by nearly every problem that exists in the realm of computer science. To the point where I wonder is there actually any problem in computer science that doesn't affect us in some way. If you've got the A type stress persona or even if you're a hacker that likes understanding things and love solving problems you're going to find working in Debian very rewarding and it can become addictive. It happens often that our lives are completely consumed by Debian which can be fun but it can also be dangerous. It's important to have something else to go to when you're having a rough day in Debian because that will inevitably happen at some point in time. So make sure that you have other hobbies too like gardening or playing music or whatever it takes just something that makes you happy that you can fall back on whenever you get a bit tired from Debian. So don't let Debian consume 100% of your life. It's healthy for you to live some margin for something else and in the end what's best for you as a contributor is also best for the project. Over the last few months I've also tried to calculate how much more volunteers we'd actually need to reach our goals to the levels we'd want and without adding too much stress on our current developers. By my thumb suck estimations I think we need if we double our capacity we'd already be doing great more so than we've ever done before but at three times we could probably achieve all our goals and as individuals be very selective on the exact problems we want to be working on. Currently too many people keep taking on too much responsibility because they feel there's no one else who can do so. I think that addressing our diversity problems are key to helping us address our capacity problems and bringing in more women and people from all kinds of backgrounds all over the world will make our project not only stronger but also more resilient. It bothers me how little local team activity we have in Africa. At the same time it's also understandable that if on average if someone has to work longer hours to be able to put food on their table that they'll have less time to work for free on a software project. At the same time we are seeing growth in some areas of free software on the continent. Python for example is becoming incredibly popular and more and more Python events are happening all over the place. I would really love to see mini debcons flourish like that in Africa too. On that note mini debcons have been growing very steadily and this year was going to be by far our best mini debcon fear in Debian before COVID-19 came along. I mentioned Africa but I think we should work on other parts of the world that are problematic too of course. I think it's bizarre that there's never been a mini debcon for the US and we have lots of users there so clearly we have a lot of work to do. Then on the topic of Black Lives Matter a bunch of us got together to put together a statement on behalf of the project. It turned out to be embarrassingly difficult for us to get that to reality. We didn't want to just put out some carbon copy statement that just wanted to grab some of attention for marketing purposes but we wanted to put something out with real action and purpose behind it, something concrete. Unfortunately we failed and I want to apologize to everyone who was involved with that that we didn't manage to carry those intentions out to reality in a timely fashion but I also want to state that it's not too late and regardless of what happens in politics and in media around the world that we can continue to further the cause of equality within Debian and be part of the solution rather than the problem. During recent discussions some people have pointed out that some of the mentorship programs we contribute to are quite expensive and they're right but those programs are also pretty much all we have right now and the feedback we have from those are very positive so at least for the immediate future we're going to continue doing them. But I do think that we have a responsibility to look at all the easy and cheap ways we can improve mentorship and knowledge sharing too. If for example a woman or anyone else for that matter but let's work in a context of getting more women involved in the project and if a woman spends just a day installing Debian, learn how to install and remove packages and some basic system configuration she'll already have useful skills that she could transfer to someone who has zero days worth of experience with Debian. I think if we're willing to spend some time and money on meetups for Debian women across the world it will very quickly get to a point where it can snowball and grow on its own. On that note I think we can also do better when it comes to onboarding. The new maintainer guide introduces someone to packaging tools in great detail but I think we should have a similar guide that introduces new members to all the different tools we use in Debian. Even just two or three pages on every topic should be plenty enough if someone is more interested in more details they can also reference it throughout the documentation that's already available. So our problems extend even way beyond the scope of all the problems in computer science as if we didn't already have enough to deal with on a technical level we also get to deal with many of the problems that exist in society but that doesn't at all mean that we should give up on either count we're one of the biggest groups of problem solvers that exist. So what can we do to fix all these problems? We could spend many hours on each topic but I'd like to propose an old idea that I think we could all work together on to forward our cause on all fronts and that is to invest more in local teams. So what makes local teams so great? Well local teams have been a powerful force in building our community already every debconf happened because a group of locals decided to take the big step of preparing a bid for their city and many of the people in our project who are minorities within the project got involved because of a local Debian event in whichever form it may have taken place. By hosting a type of events that local teams do they lower the barrier of entry to the project and at the same time they also make Debian better and they create excitement around Debian that attracts more users and developers alike. Now more users often sound like that will add more support requests but local teams also help deal with that and at the same time at least some percent of their users end up becoming Debian developers as well. Local teams have also resulted in the existence of our top two Debian specific trusted organizations namely Debian France and Debian Switzerland. In some cases like in France, Taiwan and Brazil local teams have managed to create local events that had even more attendees than debconf typically has. Local teams used to be a big thing in Ubuntu a few years ago. This was also back when they ran the Shepit campaign where individuals and local teams got free Ubuntu CDs. I personally handed out more than 2,000 Ubuntu CDs to individuals that is not boxes of Ubuntu CDs but each of them to an individual. There were boxes on top of that too but that would bring it into even more thousands. This really helped boost Ubuntu on a gross roots level the idea that they had all these free CDs to distribute. This picture is from a software freedom day in Storfest that I organized in Kailitsha which is one of the poor areas in Cape Town. This young child had just come from a dancing event close by and was so excited about the ideas behind Ubuntu that I explained to him that I ended up taking a picture of him with a disc. It's kind of crazy to think that he must be in his early 20s by now and I'm not suggesting that we start printing installation media but we should do more to allow our users to promote Debian rather than just depending on our project members to do so. So here's a few thoughts I have on how we can fortify our local teams. We could have a team delegation that takes care of a global budget and could take care of the investment process request that fits inside those budgets. We do something similar for Debian where Debian submits a budget and then they're responsible for the details afterwards once it's approved. So not the whole team would need to be part of the delegation but a delegation would be useful for those who are taking care of financial stuff. Members of a local team support group that focuses on things like creating t-shirts pamphlets posters usb discs and so on would not have to be delegated. Then one thing that the Debian derivatives team does which is pretty great is to run a census of derivatives. I think it would be great to borrow that idea and have at least an annual check-in with local teams to check if they're still up and running and whether they need any help and whether all the details we have for them on file are still up to date. I wrote here establish a process for starting up a local team but really I think that's also more of a handling process to help them feel that there's some way that will guide them and help them if they get stuck and that they have a feeling that they're not alone in this. But some checklists and things like that will also be useful. And then schedule coordinated events. I mentioned software freedom day in the previous slide. This used to be an event that ran a while back where people hosted install fests and similar Linux events all over the world on the same day every year. And we can use events like Debian Day like this which happened just a bit more than a week ago. I know that the Debian Brazil team took advantage of that and possibly others too but with some planning and coordination I think we can make a bigger deal out of that kind of event across the world. But those are just my thoughts. Bring your expertise to the local team buff hosted by Moray and myself on Saturday especially if you have experience in a local team. So let's talk about Linux and OEM laptops. So the Dell XPS range shipped with Ubuntu for a while now and Lenovo has been expanding Linux options across their product range. So at my first talk as DPL at Fikim Casa who said Debian I dived into the topic a bit and pondered on what would it take to get Debian on OEM laptops. Also would we even want such a thing because I didn't imagine that most Debian users even if they got Debian on the laptop out of the box would probably install Debian from scratch again the first time the system boots up. In a nutshell I listed three main things that I thought we'd have to get right to get Debian in shape for an OEM install and even though I thought that OEM support might not be very high priority for us as individuals I do think it's important for us to support the features that make it possible. Even for use cases like refurb centers who often have struggle with software licensing Debian would be a good option for them to install in an OEM mode. So the three main things I mentioned was have some support channel available for OEM laptops and this could be something as simple as a web page that let's sweat to download installation media how to install it and maybe some possible gutters. It's also probably somewhat important that if someone chooses Debian for their OS when ordering a new laptop that they at least have some basic understanding of what Debian is and that they're getting a community supported system. Then on the technical side I listed that we probably need an OEM mode for our installer and probably support for setting up a recovery partition since most laptops don't ship with an installation media these days. So in June the Linux technical lead at Lenovo for the PC team, Mark, reached out on our lists and we started chatting. I pointed them to my previous talk and it turns out that the points I listed was good but not all that critical. So while support is a concern their internal support team can handle Linux queries quite well and it's not really that big of an issue. Recovery partition would also be nice but currently other Linux systems don't do that yet either and this isn't that big a deal. The important part is really hardware enablement and when it comes to hardware support they care about the latest and greatest models because you know the models that we often use just aren't on sale anymore. So we ended up having a good discussion and Lenovo seems quite enthusiastic to improve hardware support in Debian and Mark even expressed an interest in becoming a Debian developer which is fantastic if we get more people from hardware manufacturers involved in Debian we can reduce a lot of friction for everyone from the manufacturer to the end user. We have some Debian developers who are still using some really old laptops which sometimes get in the way of them being productive and I thought that perhaps we can get some new laptops into the project which of course wouldn't just be another specific but the idea is that we get new hardware for our developers which help them and at the same time we improve hardware support for everyone else as well. So I expressed my concern to Mark that that it's probably suboptimal for DD's to pay full retail price for new laptops especially when we want to try to help out them as well and he actually took that up with management and guess what they agreed so Lenovo is announcing this week and I have permission to say that in this talk that they'll be providing a significant discount on all new hardware to all Debian developers so keep an eye out for that announcement if you're interested in a new machine and on Saturday there's a session called Lenovo and Debian if you're interested in improving new hardware support on Debian or if you want to share ideas on how we can collaborate better or if you'd like to ask Lenovo any other questions on this topic then this will be a good place to do so. So I've covered quite a few bits today and while we are certainly not perfect we also have a lot to be proud of we're one of the few distributions that do what we do on the scale and pass all the same freedoms we get from the software onto our users. In the commercial world there's often a chasm between developers and users in our case Debian developers are usually Debian users too so the conflict of interest that usually exists between users and developers in the commercial world just really doesn't exist in Debian. Our project is also quite healthy and is continuing to thrive it's great that we never have to make poor short-term decisions to justify short-term profits. I mention running costs too because one of our upstreams have become quite bloated in that regard and it really didn't work out. Finally we basically keep on chugging along and keep releasing Debian and with that we continue to improve in just about every direction. We're a strong force in a free software movement and if you're new to Debian and unsure how to get involved my advice is just to keep on using Debian and find things that you're unhappy with and it can be better scratching your own itch is often a good way to get involved in the project. And that's it from me if we're running on time then there should still be a few minutes left for questions. Thanks Jonathan for the amazing talk. Let's move on to the Q&A session. We have quite a few questions so let's start with the first. So the question says what about spending more money for non-developers as developers do not need money to do their job? So Jonathan? I think we just read the question again what about spending more money for non-developers as developers do not... I don't know I think it's a case by case basis so if someone has an idea I think don't hesitate to email leader at Debian.org with your idea to spend money. I think there's many areas probably as non-developers where it's a good idea to spend some money. So let's see if we can look at it by case by case basis. I think on a long term we can use that to build up a policy based on that and we can always ask for more input once we have a policy. Oh that's great. So let's move on to the second question that says Debian maintainers and Debian developer application process requires PGP key signing. So how do we do this in the COVID-19 world? Are we concerned about the dropping application numbers? So Dan recently raised this on I think either the Debian project or the Debian developer mailing list and the idea was to make it clear to Debian developers that they can use their own discretion and in certain cases you can come up with your own way to make sure that the person whose key you sign is actually trusted and the idea is to make sure that that person is the same person that you communicate with again in the future once you've signed that key. So it is possible to do something like for example I'm going to sign someone's keys over JetSea and someone who I've worked with a lot so I know what it looks like but we can't meet in person so we're just going to exchange keys like we would have in real life to have a JetSea session. Now someone asked what benefit is there in having even a JetSea session? It just makes it a little bit, I just feel as a Debian developer it's a bit harder for someone to create sock puppet accounts when I can actually see them and interact with them for a bit. So moving on to the next question it says do you think the process for becoming a Debian maintainer is not very simplified as such? It can probably still be simplified a lot but I think it has become a lot more simplified than it has been a few years ago and I think that's a great thing. We can see that in the amount of increases in new applicants that have come in so I think the more it gets simplified the more applicants will even still see after death. So true so next we have a very personal question so it says will you stand again as the DPL next year? I want to so if my personal situation allows it I probably will we'll see. Okay so next we have so I think you have answered the question here and next so another question says is there a plan by the publicity team to get paid help for instance from designers to improve our communication materials? Should this be something we encourage? So I think in that case I'll take the lazy option and once we have a delegation for local teams I'll push that onto being their choice to make and again I think we'll probably need a good policy around that. The thing is we want to be true to the nature of being volunteers in the project and we don't want we don't want someone who gets paid to do something have a higher status than someone is not paid and kind of shoving them to the side so I think whenever we bring money into something and paying someone we have to be careful of that balance and making sure that we don't get compromised on that. So I forgot to add it says that South or Debian flyers are pretty dated also so just to add to the question. So now we have a pretty long question I think we have time for that also so it says oh sorry it just scrolled down it says the Debian new queue reached all time high at the package count earlier this year but saw a huge drop around early July. This has unblocked countless important updates from Golang in the Rust packages which are impacted by the bottlenecks significantly. So it's been asked what's your take on the situation and in your opinion what would it take to significantly reduce this barrier to avoid frustrations and scale up developer activities so how you can assist the DDs it says. So the new queue is a sore point for all of us because it's not only new packages that land in a new queue if you do like an ABI bump and your library your binary package for your library as to bump it also goes through new again and it's kind of a pain point for us and many packages have gotten stuck there for a long time and it was at an all-time high at the beginning of this year and then it dropped sharply off to it. Now the reason for that drop is because there was a bunch of people who wanted to get involved in FTP team and contribute but there was also bottleneck in getting those people trained and actually getting them to be productive members of the team. Now Sean Witten has gotten involved with the FTP team and he's done a great job of rounding these people up and getting them the access rights they need, training them to do the actual work and that's been fantastic that's why there was such a big drop so I think as long as that continues things will just get better and I'm also thank you to Sean Witten for taking that on because I think that was quite a nice thing to do. That answers so I guess we have one more question coming which says did somebody say blue voltage this year or maybe we can wait for the question it says did somebody say blue voltage this year and I just missed it. So at previous DevCon I did change my nick on IRC to blue voltage so this year I haven't gotten to that yet maybe I should. I wish my hair was as awesome as Marga's hair I didn't know if you saw that in air talk this morning but her hair is a very good shade of blue but I couldn't find that at my local stores in time for DevCon. So it says thank you for the talk and date work as the DPL so we got a few minutes any final thoughts you want to add before ending this talk? Nope just continue to be awesome and do what you do. Devian people are awesome I love you all just go on NPP and do that. That's true so let's conclude this talk so I would like to thank you Jonathan for this amazing talk I would say and Cecilia for behind the camera direction. So good day. Thank you bye bye.