 Okay, so here's the agenda for this time round. I'll go over some project highlights. Community outreach. And then we'll go over. Yachto at our virtual. A bit of Lenox conference here. So. Project release updates. 2. 3.2, which is the one that we're working on at the moment. Should be releasing soon. And then we'll go over to the next one. Sometimes we knocked over here in the next couple of weeks. We have some stats on how many changes have gone in and the number of developers. Our LTS, which is the three dot one release. It's the third dot release that we've done. And so far we've almost hit 470. Changes. We have around 200 new developers. And we have around 21 developers participated in this LTS round. And then the last, the last release here, we have a Zeus. It's now in community support. A couple of weeks ago. And there's some stats regarding that. Some project. Updates. We have some new silver members for the Yachto project. Foundry IO. Also a San Juan fair Linux. The project is. Hello. The Yachto project is turning 10 years old this year. The big thing that we've done so far is. We've migrated to Sphinx. Special thanks to Nicola. Richard and Quinton. We've done a lot of work for participating in a lot of. Changes to do that. We also started a new website for the docs. That's, there's a URL at the bottom there. Docs at Yachto project.org. Some additional highlights is we've done a lot of. Out of builders stabilization. We've had several MIPS. Corrections to make MIPS QMU much. Stabler. Thanks to Cisco. We've done some pseudo changes and we will be reinstating the SWAT team here shortly. Thanks to the Yachto project members for stepping up and getting people participating in that. Also, there's a few more thank yous that we need to do. I think he's been running the bug triage, the weekly engineering meeting and monthly engineering meetings. He's been, you know, he's been. Volunteering his time for as a PM. Special thanks for Trevor Warner for doing sending out the weekly minutes for the engineering meetings. I'd like to thank Randy McCloud for assisting the bug triage and Trevor Gamblin for sending out the bug triage. He's been running the bug triage. He's been running the bug triage ARs and minutes. So as far as community outreach. We do have some virtual meetings that we hold. There's a link there where you can get all the information about signing in. The zoom information. We do have a weekly bug triage. It happens on Thursdays. And if you want to challenge yourself, you can see what tasks you can pick up. We also do have a nearly weekly engineering sync. That's where we talk about the internal workings of the project, build issues, things to help us through the next week of the October project. We also have a. We do have a monthly technical call. If you want to help shape the release. That's where we talk about. That what's coming up in the next release. We're doing the three dot three planning now. That I have a, there's a Google doc that I can share with you. That's also included in the status minutes, the status minutes that. Stephen Jolly sends out every week. So you can see what's being put in or what you can maybe help. So that's where we talk about that. So that's where we talk about that. In the next release. We also have a bi-monthly advocacy meeting. Open embedded has a. I believe it's a monthly happy hour. They have a schedule for that. And I think there's a monthly TSC meeting. Not much. I'm not entirely sure the schedule of that. Some other outreach. We do have a twitch. We do have a TSC meeting. We do have a TSC meeting. We do have a TSC meeting. We do have a TSC meeting. We put together that. Joseph has been doing for. I'm guessing up to maybe almost two years now. There's some stats. We have up to 5,000 subscribers. 8,000. Views per month. Almost over 800 hours were watched. So. Pretty cool. I think. And also if you want to, we have some links here. If you want to follow us on various. We have. LinkedIn, twitch, YouTube, and. There's the octave community link at the bottom. So at embedded Linux conference this year, we have. So far, we have already had two. Events. One is already happened earlier today. And the last one for today that I know of is this event. For tomorrow. There's the best practices. Scheduled at. 1300 GMT. And then on Wednesday, we have a couple more. Round it out with the. First, the octo projects first decade with Jeffrey and Nicholas. Posting that. So that, that'll end on. Wednesday. We are also having a summit this year. It's at the end of the, this week on Thursday and Friday. It's not too late to register. So there's a link there. We can register. And sign up for those two. Center for the summit. If you want to look at the schedule, I included the schedule for the summit. There's effectively two beginner sessions. In parallel with the 20 intermediate sessions. And. There's also going to be a hack room. With three hands on. And now this is where we turn everything over to the community to ask questions. Okay. So I've been monitoring the chat. So it looks like there are a few issues. People can join through the. Web interface or through zoom. So I think I would recommend everyone to join on zoom just to make sure. I think there is some sort of integration between the application, the web application and zoom, but it looks like zoom works better for most people. So we are definitely on zoom. And yeah, so that's, if you have any issues, just try to click on the chat button and try to zoom link. So, yeah, so that's where it's difficult. The first question. The first microphone. That's always the same. Yeah, the rule is that try to, I know you should be able to unmute as well, but in general, if there are many questions, maybe we'd better to just ask the questions. Yes, I can see that Dave. We can ask the questions on chat and then we'll try to answer the questions or ask anyone. So I see that we have many key people, key developers from the project. We have Richard with us. So hopefully we can take any questions today. So anyone wants to volunteer with us. So can you hear me? Yes, that's works fine. Yes, I would be interested to know how you guys are dealing with NFS route in Yachto. So some other BSP build systems like PTA exists that I use, they have an NFS route mechanisms that just extracts a directory for you. That's called route where your root FS is, and it patches the permissions for the files and folders. So I can just point it and use it. But with Yachto, what I have been using so far is that I extract a table. And then if I run into SUID problems, I have to fix them up manually. So I wonder, does anyone have a ready script set of it, maybe using iNotify or something, or how do you guys do NFS route? So this would be something I would be interested to hear what you guys do. Okay, so I do not have the answer, but I'm hoping maybe somebody wants to speak up. Richard, I see your unmute, but I don't. Yeah, I kind of nobody else wants to go. The project actually has its own inbuilt NFS server. So the user space NFS server, which runs under sudo to handle the permissions. So I can't remember the names of the script offhand, but there is some kind. If you look in the script directory, there's something involving NFS root in there. And that allows you to take a root FS table, extract it, and then use it as an NFS, as an NFS server, which you can then point a given kernel and piece of hardware at. So that technology should be there. It's probably not as well documented as it should be, but if you have a look in that directory, you should see some scripts that will let you do that. I'm fairly sure that it's actually tested in one of the self tests as well. Okay, so I can just rerun the build and it will automatically put the newest files at the correct location. That technology will let you host it and get the permissions right and everything else, but you probably will have to re-extract the root FS after you finish the build. I don't think it dynamically updates in place at this point. That's something which would be quite nice to add, but I don't think it automatically does that at the moment. Okay, so I use it often. I use it a lot so that I can just develop on some software and just build in my BSP and some new defences updated. It would be great to have this new octo tool out of support. It should be as simple as adding some kind of our sync or something like that between the two directories run and sudo at the end of the image task or something. There's probably options there, but like I said, it's just not done quite like that today. Okay, I'm not sure how well that would work that you just replace too many files at once while the corner is running off it. But I'm not sure about the limitations. I'm just wondering if there's something I will try. I've done that with my in-house boards where I will upload onto an NFS server and just have my board auto mount that when you boot comes up. So every time I build, I'm sending up a new copy of the root file system to my NFS server and just do it that way. I wrote a class for it. It's in a meta lab. You can haven't registered it on the layer index yet, but it's what I use for at home. Okay, so it's kind of it's kind of a crude way of doing it, but it's way around it. I should share. I should probably register it so people can use play around with it. I'm more generally with, I mean, if you need to, I mean, we'll try to take question and answers today. If you need to follow up and if you thought if we talked about something at the bottom and you want to follow up, there are many ways. I mean, the Yachter project mailing list would probably be something now that you've talked about this thing you can send an email and hopefully, I mean, others can follow up on mailing list. And then during the conference, most of the people and most of the project developers, we've decided to use a Slack instance. So if you go on the Yachter booth on the ELC main page, you will find a link to join the conference channel that we decided to use all week. So you can find us there and ask questions, more questions or need to follow up on anything. Yes. Well then, thanks. I just arrived literally on the slide after Armin misspelled my name. So I've been told you owe me a beer. But anyways, more serious knows. We've had some discussions on local as content, like German, Italian, Chinese, India, things like that. So it would be awesome if we could get some input by our user base. And if there is a need for that, what are the formats that are most interesting for the specific regions. For example, I've been told that India almost has no use for written documentation. It's all videos that they consume. On the other hand, in Scandinavia, it seems to be only written documentation so where should we be heading that would be really interesting for us. So what Joseph just mentioned, it's a discussion that the York to advocacy team is having these days. I think it started a few weeks ago. What we realized is we have a few people who are to produce content in like, I mean, Italian, Japanese, I mean, we have different languages and that's something the project itself. I mean, the documentation and everything we write is mostly in English. But we are looking at how we can actually explore and how the community can actually grow and just produce languages and different materials documentation into different languages. I think Joseph, you said that you are ready to do that in German, which is good. But yeah, so if we find more people that wants to help with different languages and then the next question is what kind of content we need to create for different languages. So that's mostly a question for non English speakers. If you want to explain to us, I mean what you think would be useful for developers around you in your own country that would actually be a very nice input for us. Anybody wants to take a peek. Seems we're scared everybody. Or maybe we should ask the question in different languages, maybe. Maybe. So that is a comment from Leon. Yeah, so I mean like we talked about translating the whole documentation in various languages that would be way too much work. And to create content that I mean trainings or things that can help, I mean, spread the doctor project in various countries. And in the end, I mean, yes, I mean the whole documentation, it would be very difficult to get that in anything else in English. I guess I have to say that this should probably more surf as entry level documentation or entry level material to get people up to speed, because if we would really translate the higher level documentation. It would it would just be like ambiguous in the end, the one refers to the German one, another one refers to the English one. And that that's probably not really good if we have. It really comes to the to the to the core material, having stuff in English is the one single source of truth and that that should not be discussed. Actually, I'm really talking about stuff that that gets newcomers in how we get people interested that are not like starting out with a mega manual. Okay anyway the key thing here is to let everybody know that this is a topic that we are concerned about. And I want to get further with your friends colleagues and want to get back to Joseph or myself. And if you have any specific need in any specific languages. Joseph myself would like to make some progress there so and again I mean it's something that we, if someone steps up and wants to help that we will help them, but it's not something we will be able to do ourselves, obviously. So if you need anything if you want to get back to us or talk about that. Yeah, just find Joseph or find me. Great. Thanks. Yeah, I agree with your comment Leon. Some conferences are more local than others and that would be so then we will need speakers at these conferences. Definitely. Okay, so maybe while we wait for the next question. We talked about the Yachter summit and the introduction so it's a big event for us. We had close to 200 people last time just joining us for like one day. This time we do a two day event with many different, I mean, a few different tracks, including trainings for beginners people who want to learn about a project and get started with the projects we definitely really hope that this is going to be a good and successful event. It's going to be held this weekend Friday. This week after this conference, and it's still possible to join so if you want to join or if you have any specific issues, you can find me or David, David Rainer who is also organizing the event, and we will help you guide you for that. We know how many people are signed up for the summit so far. Let's check. I think it was a week ago and it was 150, but I'm not sure. I mean I just give a number but I'm not even sure about the number. Okay, so again, still hopefully we'll get more questions. Since we have sorry to put you on the spot Richard, it's almost a new release. What's 3.2? Do you want to talk about what's coming in 3.2 and hopefully that will make people ask more questions? That's a good question. It depends on what people are going to contribute to be perfectly honest. 3.2 is way too late to contribute. Oh, sorry. Right, right, right. I thought you were talking about 3.3. Yeah, 3.2. Well, as you said, I mean one of the biggest things is the documentation transition over the Sphinx. I kind of see 3.2 as a bit of a more of a stabilization, but we are, we have managed to update a lot of the recipes to be probably as close to upstream as we've been in any of our releases, which I think is good. There's a lot of patch overhead and sort of, you know, the number of patches we're carrying to various bits of software is slowly shrinking over time, which I think is very positive. There's a lot of sort of smaller changes in there, such as the pseudo fixes, which I think are going to really help with some of the rare but important sort of corruption cases and so on that we've noticed and we need to fix. Yeah, it's, in case people are wondering 3.2, we did have the RC1 build, which has just come out of QA. Unfortunately, one of the patches that I broke one of my rules and took a patch at the last minute. It's broken things so we're probably going to have an RC2 that will go into QA and then hopefully we might get the release out by the end of the week. We'll see. But that just gives people an idea of what's going on with the release. Was there anything specific you wanted to talk about, Nicole? I'm just, I mean, I think it's good for most of the core people know what's going on, but I think we have more people here today so it's good to know. So 3.2 is coming and as expected, and that's good news. Well, shall I say something again? As you said, the crowd is too shy. Okay, so one topic we had last year in Lyon was the question if we are, we are doing good on diversity. So if we are still all white angry metalheads in our 30s or some in our 40s by now, or if we are like how we can get people from other backgrounds in and how are we doing there? Is there some progress on it? Yeah, what's the feedback? I know that some people got in touch with that over outreach and at least for Tim and me I can say we are trying as much as we can to help those and get them up to speed. But yeah, are there others who feel like they need some assistance or yeah, please step up and let us know. So I mean I think it's a very important thing that you describe and it's definitely an issue for this community. And I encourage everyone to attend the event on Wednesday about the 10 years anniversary of the project. And yeah, you might realize that this is an issue for the project when you see the pictures and the people who have contributed. So, and we are in a very special place in the embedded Linux space itself. So we've tried in the past to do things and we've worked in the past with for example the outreach organization that makes like, I mean internships to try to reach out to people who usually I mean we might be actually difficult to reach out to. So what we are trying and again I mean it takes a lot of energy from people from this community to actually go and do these things and I'm very happy that this year, we have been able to propose two different internships to the outreach. So they're, I mean, actually, this is October so by the end of this week, we will do, we will close the selection of interns for two different topics for the October project. So it's only possible because we have people in our community who just step up and just want to do that. And there is a bit of finance side of things but that's usually easier to get the finance side of things and actually find people really want to step up. So we definitely what we've seen that I mean as soon as we open up the outreach sheet like a few weeks ago we've seen that I mean a few new and new people joining. And with different background and they just were very interested to start learning about the project. So we already saw some positive things about that and we really hope to get more. So we will support and we will help anyone now coming to you wants to help us with these kind of issues. Yeah, so you know Trevor Warner has been trying to get Google summer code going and you know we just haven't quite gotten there yet. I was really glad to see us get the two outreachy internships in there. It's hard to get connected with the right people and the communication and the whole process of onboarding the applicants is tricky. But it's still just very exciting right and you know, many of you realize I taught in university for five years and if you count all the time I was in grad school it's way more than that that I was teaching. It's very natural for me to be a mentor and, and I love doing it so you know I'm, I'm putting my money where my mouth is or, you know, walking in the walk in that regard, the best I can. Yeah, thanks for that. And I mean even though I mean doctor I mean looks like something which is deeply embedded. It's actually fairly straightforward to get started for anyone. I mean we talk to interns that mine for the outreach we let them know that they don't even need like a super powerful machine we can provide all the hardware for that we can provide them in cloud instances and we can help anyone I mean who sometimes that might be like a barrier to entry. So we will do anything we can to help. Again, just try to reach out to more, more people and what we have today. But I think it's important to sort of stress that this all comes down to community support of these initiatives because we have tried to get these going we are short on mentors. And there's a tangentials topic which is the inclusive language. And I think that the next release is going to see, we're going to need to make some changes, and those changes are going to be relatively disruptive because we do have terminology in there that probably shouldn't really be in there. But we have put some proposals out about how we should go about that and put a roadmap there. Everybody I think is in, you know, is an agreement we need to go fix this, but actually people stepping up to do the work has turned out to be a little bit tricky so far. Now I have deferred it to three three because it was getting too late and three two to take invasive changes like that. We do need to address it in three three but we are going to need help. Some of the people here, you know, yes as the people, the contributors we all know, but I'm also hoping we may get some new contributors who can help us with with some of this work. Yeah, that's right. In fact, there are even changes that can be done by people who are not very familiar with the project, I mean, especially with the inclusive language. And they are technical change with changes want to make their things to review I mean help with the documentation. And so, you don't need to know everything about the project to get started with that so that might actually be a good way to just get started with us. Yeah, and there's there's examples like, you know, toaster and the layer index and things like that that are in Django right and that's a completely different skill set, completely different group of people that would would likely be interested in doing that. And that's very different than the normal core folks in our traditional usage. It's worth highlighting as well that the documentation transition over to Sphinx does mean that the documentation is now much more accessible for people to make changes to because the doc book syntax was pretty horrible to try and work with. It's much easier to read and to make changes to and to review as well to be honest. So I think this, there are sections of the manuals that are dating and need improvement, or those just things that are undocumented and so on. But I think, you know, that's another area where new contributors can very easily make a big difference the project as well. Richard I think that's like a very strong point and once again thanks to Nico for such a heavy lift on that but you know I was reading through something in the manual just the other day and realized, oh there's a link missing here and, you know, the barrier. So I was very comfortable with doc book that wasn't really the problem but to actually build it and test it was non trivial. And to actually make changes is very low it's it's about the same as just making a change to some recipe now. It's really really nice much different situation. I think that's one of the best things we did this year. Yeah that's correct to change and that's that's right I mean the building and rebuilding the whole documentation and locally testing the documentation is now just become like a one liner and it just take a minute. So that's that's very big change yes. We just need a recipe now to build an image. Could build that with speedbreak yes. Okay so while we think that we are waiting happened so we have a few questions now. So there was a question earlier so somebody I'm just going to quickly repeat the question or the sentence. So I would like to talk about what Chris talked about compiling your to and they be and the big difference is in developer experience for application application developers, having a binary package feed. So, where are we with your to in terms of consistent experience for package feed for creating this store. I used what we have now this week in my own development cycle, based on a talk that Stefano Chitola did back in 2018 at a Yachta project dev day. So, the problem is that what people mean when they say package feed isn't hey, can you use that because we've had that forever right we've had the ability to put a package manager in and build your own package feed and use that. The problem is having a publicly available package feed. And there's a lot behind that. You know there's all the maintenance of it but there's also liability once you start actually producing binaries and making them publicly available so it's just not a not a simple solution. But people are definitely working on that. I think that, you know, in the past it would be very difficult to do something like a binary package feed. You know, we've seen distros produce them. We went through phases where there were challenges in that I think the situation has improved. Particularly now we have hash equivalence we have reproducible builds and so on. I think that will help tremendously with things like the auto increment DPR values and things like that. I think it's probably a time when somebody could you probably need a team of people to do it. This is a challenge. So if there is a group of people, you know, fellow co travelers who would be interested in doing that and can define the parameters of that binary feed, then I think the time is ripe to do it. But it's going to need people to step up and do it because the current sort of contributors working on the core of the project don't have the bandwidth. So it's a step beyond what we have today. I think the technology is there now it's it's just going to need the people to drive it. This is this is Walt that was the one who typed in the question. Just to be clear, I'm talking about a package feed not of the Yachto project packages themselves but now that I once I've built my distribution based on the project. It's a dream feed from there. So are you talking about Walt hosting your own, like having a GL host their own. Yeah, so a GL a GL wants to have a package feed based on a Linux just based on a Yachto distribution and those, like, I think I think Richard just said there's a lot there's work that needs to be done and somebody needs to step up and do it. I'm just wondering if there's any, any, anything more in flight from from the actor with the actual project itself. We've been talking about it but you know what you're talking about for a GL is absolutely doable right because you've already got a CI infrastructure so essentially once you've done your build, you would need to run the package index task and then basically run it back to our sync that your, you know, deploy IPK or deploy RPM or whatever package manager you're using directory to your web server with the thing that's actually going to serve up the package feed. So I just did that a couple days ago so we can talk about this offline or whatever but yeah that would be. Yeah, we should have young Simon says he's having trouble joining. It's a good discussion to have with with the on Simon as well. Yeah, I mean, I'm happy to go over that with you guys and in some detail because I just did it again. Okay, for the first time in a while. It's really easy to get that first package feed it's maintaining it where I think there's a little bit of exploration that's going to be needed and I think, but I think the tools are all there. I think that Mark Hadley did try this integrating hash equivalence and PR service and things like that. It's not entirely perfect but it's not far off either. I don't see huge issues, particularly now we've got the reproducibility pieces and the hash equivalence, which means that this defeat stability is there, you're not having everything change every, you know, every time you rebuild or anything. So it's close. It just needs somebody to actually go and try it and have a little bit of time to fix the inevitable bugs that you're going to get when you try something new. Yeah and it's something like you know in the fedora project you've got the nightly compose that has to happen which takes, you know, all the builds that come out of Koji and puts it into the various spins and images and so on and that extras. Those extra steps that make the thing consistently and robustly and reliably up, upgradable and downloadable that those are the extra steps that we haven't as a community been doing because we don't have that infrastructure. So those are some of the places where AGL would probably find some stumbling blocks but it's not insurmountable. And the infrastructure or sorry the code, the metadata, the tools are much better off than they have been in in a long time and in what in my recollection. They're very stable right now. And I would give a mention you asked about new features in this release that interaction between hash equivalents and PR service is something that was fixed by Mark Adley in the release. So that's something new in three two that will definitely help with this because it is being used for what you've just described basically. Yeah, the problem for us then is that we've chosen to stick with the LTS release so we need to think about how how we can make use of that. Right and the changes were fairly invasive for whatever member so we, but it's something we should we definitely need to look into and figure out whether there is a, you know, an extra layer on top or something that this could be done in or whether the changes because they've stabilized in master would become suitable or what our general plan is going to be for that kind of right. Okay, so that was another question earlier. I'm just trying to look at the backlog. Is there anything that blocks live set come to actually be merging to OEC or another the pseudo issue as I've been fixed. The child might again be for you. The pseudo issue was fixed by just aborting and not running anything to do with that comp. We just disable it. So, I think that tangential issues I'm not sure why we why what we need to be needing to import that for. I already answered that so there's discussion on that page ongoing. Okay, I'm sorry. And it would be interesting system day because the system day system call filtering depends on that. Okay, so trying to move to the next question. Someone is asking bill is asking about rpm versus opkg versus step is reporting that there is probably less used, but you wanted to get a feeling about how people use rpm as opkg and reports that opkg might need a bit of help. The main project is mostly using our DNF and rpm packaging. So those are that's the most tested IPK and opkg package are tested quite a bit as well. Debian's just currently the least tested and we really just need people people that are using it and want to use it to be involved and help us maintain it. We definitely have limited numbers of people involved in fixing things right and so people that want to use something else. We just really need you to, you know, come join us and get involved. I would say I've never had any issues with either opm or opkg, certainly within the last few years. So those are the two I would recommend people use. The question was whether there's a percentage and I don't think any of us have a percentage as to what split is I know both of those are used. We've got at least two open bugs against the Debian back end from the same functionality. And we're struggling to find people to add it because we don't seem to have the user base there. But what the percentages between the two, I don't know. This is one of the problems with open source, you can't tell exactly who your users are, you can just go by bug reports. We know that opkg and RPM are both used. Okay, so there is a question about the industry grade Linux asking an apparatus from assuming this is followed up based on the earlier keynote or presentation. Has there been any discussion with the LF about that because it looks like that Yachto could actually solve that much better. So I guess it's a very open question. So where I don't think there has been any discussion, but I could be wrong. I'm not aware of any specific discussion on that topic. I know some of the people involved are aware of Yachto project so you would hope that, you know, it would be something that's being considered in that space. It's probably if people are if anybody is involved with that, you know, talk to me and yeah we should at least try and figure out a way of connecting to that community to make sure that we're at least being considered. But yeah, it's a good question. I'm not aware of any discussions right now. Okay, just looking at the time. I think we have five more minutes. Just trying to find if there are questions. Any discussion about OPEC HSS RPM and I don't see much questions. I don't see any other questions. Hopefully I'm not missing anything. Okay, so one last one last or last two questions, maybe LTS status maybe we could should we talk about that. It's been six months now, maybe that we've launched and talked a lot about LTS. This has been a key request to the project members quite some time and the project was very happy to announce that it managed to figure out how to deal with LTS and do LTS. So, as anybody using LTS as LTS changed the way you use or rely on the project. Do you have any feedback on what we could do better or differently. So I'll say internally that it was much easier to convince all the teams working on different platforms to switch to LTS. That was like an easier sell than we've ever had for getting a team to upgrade to a newer Yachter project version so I hope that's happening everywhere. I have heard that from a few places as well. That's definitely I mean one of the hope that we had reducing the number of key releases that people rely on just like by having one big LTS I mean of course we still want people encourage people to use the latest release. But generally these people should be able to grade more often than the others or hopefully they should be able to keep up with the pace of the release. Starting up a new project and it's literally helped adoption with having LTS there. One thing I'll say is that if people are finding the LTS useful please do give us the feedback if you can to show who's using it, why it's important because the project needs to be able to fund these things. And to be able to fund them we need to show that they're actually being used and they're useful to people. So it's kind of like it we can end up in a catch 22 situation where everybody's really liking it but it's working well and everybody stay silent. So if you can give us feedback and show us that these things are being used that does help us in, you know, then try figuring out to be able to try and fund them and keep them going. I just want to make sure people are aware of that as well that there is a connection there, showing that these things are being used is important to help us make sure they keep going. Because obviously the members talk to each other about it. But if we don't hear it from other users in the field and we really don't know. There was a question about the length of the LTS policy. It's tears right now. That was the question right. That's the length. Yeah, so the length is two years. Again, I mean, everybody should realize that there is there are finance things associated with LTS and it's more work and it's dedicated engineering work. So at the moment, we have secured the funding to do one LTS, which means that when we start an X one after three years, we will have to decide I mean, I mean we won't be able to do two LTS. The hope is that we'll see. I mean, we assess the situation when it's time to get there. And if LTS is a success and if more members from the project want more funding to go to the LTS, we might be able to do two LTS simultaneously, which means we can extend the first one. But this is all things that we we differed for later. So we wanted to put the process, a good process for LTS and then I mean we'll see I mean what the feedback is and how to deal with the next LTS. But two years is what we set for the goal. Feedback PGS for feedback mailing list or just talk to Rachel talk to me talk to I mean any of us should be able to just relay the feedback. But something on, yeah, something on the mailing list or sort of if it's if it's sent to one of us in email or something like that, we just need to be able to show that there are people using it and how that really does help us. So, yeah, anyway, we can show the support. We also put a page on the wiki, trying to show which projects are using the project. And I think having something about LTS support in there could also be good. But yeah, any way we can show where the projects being used and why it's important really does help us immensely. Okay, and I think this is it. So this is the end of the buff. And again, there are many ways for everyone to just join and talk to any of us. In the national the ISE the mailing list your project slash community and you will find all the details join us. And there are a few presentation during the week this week at the event. And there is a doctor project submit at the end of the week, which is a dedicated event to the doctor project and open embedded so thanks again everyone for being with us today and I hope you will have a good rest of the conference. Thank you.