 Hello, everyone. Can you hear me on the mic? Okay. Yeah. It's very difficult. Right. So, good afternoon, everyone. I guess when you came here, you didn't expect so many speakers at the same level. So, but this is going to be a little bit different than any other talk that probably you attended today. Obviously, the title is meet the maintainers. And you can see some of us here already lined up, you know, to, to participate in the discussion, take questions, and so on. And I see a few other maintainers sitting in the back, not coming in. Hey, can you guys see me? So, why are you hiding? Yeah, there are two. Yeah. So, Fabio, Keith, come on, join us. I love a chair. And broadly, Kate, as well, should join us. You are the maintainer of the whole project, right? Okay. Okay. So, I mean, the idea behind this is, so over, I think a few years ago, two years ago or something, we introduced this, you know, the concept of project roles, and we defined different roles in the project and how things, you know, get managed, get maintained, how things get reviewed, how, how, how we, you know, all for the sake of making things more efficient, and to move things faster in terms of like contributions being reviewed and merged and integrated in, you know, releases as fast as possible. And doing that, we introduced the roles, as I have said, we have the maintainer role, the collaborator role, and also the contributor role. And that, like, different responsibilities and rights come with that. The whole idea is to, you know, elevate or help drive the maintenance and the development of areas in the project and make that official and also offload lots of the work that we have to do to get certain, like code changes and introduction of new features reviewed. So, that's why we try to follow this model where for each subsystem, we have a maintainer who is an expert in this area, has been involved in this area for a while, probably introduced the subsystem or this driver API into Zephyr, and is considered basically the last word in terms of, like, you know, accepting changes or introducing new features into the subsystem. Obviously, as you can imagine, over the years, this, the areas in the project have been growing rapidly. So, I don't have statistics right now, but I would say that we would have, like, a new area, like, every other week or something like that, yeah. And the, you know, the problem that we have that we have been discussing also earlier this week is there's a lot of, a lot of movements in the project. People, you know, come in, introduce something and leave for another job or another opportunity. And there is lack of maintainers in general for some key areas, yeah. And we wanted basically, you know, using this opportunity here at the conference first, you know, to introduce ourselves and talk to you directly. And I assume, you know, some of you have different levels of involvement in the project. So, there obviously will be different interactions. We definitely don't want to go into architectural details of, you know, how, you know, why my PR was not approved or things like that. But it, I mean, every topic is fair game here in terms of we want to identify or know about pain points and problems that you might actually have as contributors or people who want to do something with the project, things that we can improve and make life easier for contributors and also for maintainers. So, that's basically the general idea. And we want to, the general expectation here or the goal of this to make things better and to be able to scale with what we have in the project and how we have been doing the project. Given that, as I said, we have new areas, you know, every probably other week, we have lots of contributors, lots of, you know, lots of features, lots of changes coming in and that needs to be managed somehow. And although we have many people here, it's still not enough, you know, to drive or accelerate the development in the project. So, with that said, I want actually first to go through the people seated here and have them introduce themselves briefly what area they are maintaining. So, you are familiar, probably you already know, you know, some of us here. And then I want like to ask general questions here to see, you know, who is actually contributing here, who's interested in contributing, who's, you know, has general questions and so on and that where the interaction and the discussion can start, yeah. So, without further ado, I would hand to Mahesh who can introduce himself, yeah. Thanks, Anas. My name is Mahesh Mahadevan and I'm from NXP. I maintain and support a lot of the things that is done at NXP. Some of the drivers that we've added, there's a lot of contributions from the community that come and we help review and merge that in. There's also a HAL that we have inside Zephyr that is, that has a lot of the NXP code in it. And we use community contributions in that as well. So, those are the two areas that I maintain under Zephyr. My name is Jim Legras. I introduce and maintain the SD subsystem in Zephyr. I'm Ryan Erickson from Laird Connectivity and I am the Modem subsystem maintainer. Hi everyone. I'm Mahesh now. I'm working in the Linux Development TMI Texas Instruments. I step in, stepped in as the TI platform and maintain and ask for respect. Chris Freeds, POSIX API maintainer and FPGA maintainer. Talk a little bit louder. Chris Freed, POSIX API maintainer and FPGA maintainer. LTS2 release manager as well. I'm Carlos from Nordic and I maintain Bluetooth, particularly HCI and documentation as well. Kumar Gala from Analog Devices have been involved with the project for a number of years, maintained ARM over the years, some other subsystems, but most more recently kind of device tree. I don't need that. Anna Snasheff, I maintain a few subsystems. I had to go through my head again to remember what they are. Tracing the test framework, Twister, some x86 related items, extensors, platforms from Intel and probably a few other things like where I'm a collaborator. This is exactly why we need to have this conversation because as you can imagine, some of us here maintain a few areas and we need to improve that. I'll hand it over to Brics and you can do this. Thank you. My name is Brics. I'm at Vestas Wind Systems. We do wind turbines using Zephyr. I currently maintain the EEPROM drivers and the CAN, controller and network subsystem and drivers in Zephyr. We've been using Zephyr for last five years and using CAN of course. Any CAN related questions, feel free. Hello, my name is Erwin Guryu. I'm working for STiMicroelectronics. I'm a maintainer for STiM32 subsystems, so STiM32 drivers, boards and stock descriptions and so on. I'm also maintainer of the HLSTiM32 module and maintainer for the shields. You're on Fisher from Nordic. I'm a USB maintainer, a driver and subsystem and what postman do you know? And I'm also looking at USB device controller drivers sometimes. Hi, Kevin Townsend with Lunaro. I'm the maintainer for 32-bit ARM that's trusted for more M integration and Zephyr Scientific Computing Library. Hi, I'm Carlo Cayone. I work for Belibra. I maintain the ARM64 architecture port, the IPC service subsystem and a couple of other smaller APIs. Hi, I'm Martin Jäger from the Libra Solar Project and Small Company and I maintain and originally introduced the TaskWatch Dock and the DAC deck driver. And I'm also quite involved in the CAN development or interested and Laura one. Hi, I'm Fabio Baltieri. I work for Google and I introduced and maintain the input subsystem and I also try to merge patches, but usually carless. I'm Keith Short also from Google. I think the only place I'm actually a maintainer in the contributor file is for code style, but documentation that I've been playing, taking a larger role in defining what all the project roles within Zephyr are and doing things to establish guidelines for both reviewers and contributors in Zephyr to try to improve the velocity of the project. You're also the process working group? Yeah, I'm the chair of the process working group, but just took that over from Marty. So that's only very recent. Okay, great. Thank you everyone. So any mentors are still sitting behind? I forgot to mention. I mean, you came all the way from Australia. Jordan Yates, I work for the CSIRO, which is Australia's national research organization. So I'm apparently the maintainer of the SIEMSIS DSP subsystem. So that's like machine learning sort of integration into embedded stuff. Great, thank you. So let's go ahead. I forgot. I'm also the thrift maintainer. There's a lot. I know we didn't go into like collaborator areas, but C, C++, there's a bunch of them. You have to actually grep the file. Okay, so now the question to the audience here, how many of you here have contributed actually to the Zephyr project? At least one batch, one PR. Okay, that's great. Okay. And how many of you are trying or plan to contribute and trying basically to figure out what the hell that is and how this works? Okay. That's also good. Yeah. So, okay. So, I mean, let's start with the interaction here. At least with have the conversation with those who have contributed. And please, if you have a question, come forward and talk to the mic so everyone can hear you. And it's also being recorded. Does anybody have any general comments about how the project is managing the contributions, the project roles? Are you looking for clarification or do you think the way it is being done is good enough that satisfy your needs as a contributor? Is there any interest of people here to become maintainers and wondering how you become, you know, move up the ladder if you want from contributor to collaborator to maintainer? Please go ahead. Let's start. Yeah. All right. So, a few of you may know me, Dan Klausky from Ampere Computing. One of the things that we've noticed is if we put up a PR that isn't exactly something the Zephyr community itself was going towards and an example I can provide is the work we did on getting LTO to work. The discussion. Can you bid that or the what? Sorry. Link time optimization. Oh, okay. Yeah. Sorry. LTO is the short. Yeah. What we found is, you know, the Zephyr maintainers for the build system cloud out came in and said, doesn't work. And that was the end of this discussion. We couldn't take that discussion any further. It seemed when we tried engaging offline or out of the PR, it just died at that point. Now, I have evidence it does work. We, we boot with it. So, I've left at a point of how do we move forward with this? But it's not just like that MR or that PR. Sorry. There's several other PRs where this has kind of happened where people have renamed MACRAs from having Z underscore to something else, right? That's an older one, but it seems to be a constant where there is a PR brought up. It doesn't follow exact mentality. And somebody basically says, no, not like this, but doesn't provide steps to move forward from there. And so how can we get those next steps from you as the maintainers to make this sort of thing happen? Okay. Tell us, do you want to answer the first one regarding proposals? Yeah. No, no, no, no, not in general, right? So just I'll follow up with the LTO stuff, but, but outside of the context here, I think, I mean, the key thing here is how often does that happen? Because, you know, there will always be examples of PRs that went wrong. The question is what's the frequency with which frequency they appear? I think we need to strive to because there will always be misunderstandings. We're humans. So dealing between humans, there's always inaccuracies and, you know, feelings involved. So, so to answer your question, I think the actual way to get around this is escalation. So if you feel that the proposal you've made via PR has not received the attention that it deserves, I think what needs to be done is a mechanism to escalate that because if the maintainer has not given it the time and effort it deserves, right? Then you have to have a way. And we do have that to a certain extent, but I'm not sure if it's enough. So we have that to with extended documented. So we have several things. The first one that comes to mind is the dev review meeting on Thursdays. That's the first one. There's also the PR help channel on Discord. So I'm not saying it's a, you know, perfect solution, but it definitely helps in many cases. And then there's the TSC as well. TSC, anyone can join the TSC and you can ask for a topic to be added. Now, whether a particular PR would be discussed at the TSC or not, that's, but, but, but really in order to have, because there will always be conflicts of way one way or another, I think the only solution to that is have that a mechanism to object to that, either behavior or, you know, opinion so that others can weigh in. And then in the end, take a decision together. No, Carlos, I think I handed that to you because you lead the architecture working group. And that's where general proposals like this, I mean, that's also another bath that I mean, there needs to be on RFC that you, you ask Carlos in this case to schedule, you know, I mean, that's another bath. So yeah, so the thing with the architecture working group, typically we don't, sometimes we bring these agreements, but more often we bring RFCs potential into the, you know, new functionalities effort that has been presented in the form of a, of a request for comments plus a PR usually, and then we discussed that before. Now, in some cases, we also discuss particular PRs that are stuck for whatever reason, no, either, but we don't typically discuss what I want to say is that we don't typically discuss PRs that have been abandoned or, you know, that's more for every viewer for we typically deal with these agreements, these agreements and, you know, and approaches, we discuss approaches is this approach, you know, agreeable to everyone. Or here we have a fundamental disagreement that it's, you know, that has been discussed up until two days ago. And now I want to discuss it, that type of thing. So, but when you were saying no one like, you know, crickets type of thing, you know, and no one, no one's saying anything, that's not for, for the architecture working group. So, but yes, that's another tool, yet another one. So, so you can escalate, I think in many different forums, and they're all valid. And, you know, I think we could do a better job of documenting, which, which is more adequate for. Yeah, so we, I think we recently did that in the, as part of the process working group of documenting, and I think Keith can probably talk a little bit more to this, because I think it was, he was the one actually adding the docs to, for that, you know, and some of this was related to, you know, sometimes towards that problem of like, you know, so there's a couple things, right. So there's one is sort of the, the general issue of, hey, you see this happening time and time again. And so I think, you know, the process working group is an area also that things don't, we don't typically, I think, mention and have community people, and it's open to everybody. But I think it's an opportunity to say, hey, I've seen this happen a couple times, you know, is there something from a process perspective that we should try to be doing better, looking about talking about to sort of see how the project functions that, you know, that if it's, if it's, you know, sometimes it's a case of, you know, maybe it's an overloaded maintainer, right. So that's just hard for someone to get, you know, responses because we don't have enough people in that subsystem. You know, I know the built systems one is a good example where, you know, I know Torsten from Nordic is the maintainer for that and there's a lot of stuff on his plate. And so it takes sometimes a long time for him to have the time in bandwidth to kind of go through everything to the level of detail that he'd want to. And so that's one where we need more people involved in that subsystem to help with some of these type of issues. So I think there's some different aspects to the kind of the problems to understand, you know, and sort of figuring out how we get feedback about the community, the community of maintainers to say, hey, you know, we're seeing this issue as a community of, you know, we're not getting responses, right. And is that a maintainer is that, you know, different subsystems and so forth. So, you know, we don't obviously have some type of, you know, way of reviewing how maintainers are, you know, working today. And so I think that's something that, you know, getting feedback from the community, like, you know, re-raising is helpful because that's the only way we know how to try to address these issues. Keith, you want to say something regarding the expectations? Well, the only thing that I was going to add is that out of the process working group, we came up with a new process of starting to triage PRs in the dev review meeting. And so that's only been happening for maybe the last three months. And right now, we actually need a volunteer for the dev review meeting to start sharing the dev review meeting because Marine has right now left the project. So right now there's a gap there. So we're looking for volunteers. So if anyone wants to help out with that, that's kind of our next step. Just to comment to the second point about getting some feedback on your PR and asking for changes, but maybe not being explicit about what those expectations or changes are, I'm definitely aware that happens. It's one of the difficulties in any busy upstream project is sort of getting those things merged in. Generally, though, I would say that the first thing to try is just post a comment on the PR and say, can you explicitly give me a sense of, okay, what precisely are you looking for? Often, it's just that the maintainers have 40 fires to put out and a lot of us have day jobs as well that have other obligations. So I've definitely been in that position where I've got a complicated PR and things tend to fan out in five different directions, and this guy wants this and this girl wants this. But sometimes maybe just a ping to say, can you be a bit more explicit and precise about what you'd like to see? And if that doesn't go somewhere, then get on Discord or get on one of the calls or ask for it to be added to the agenda. But sometimes just that ping because people forget about it, or they put a comment and they assume you can read their mind, but obviously things don't work like that in the real world. So sometimes just an extra ping to get those next steps. And I see this a lot, especially with newer contributors who just struggle with something like it. Like, someone's going to say, oh, you need to rebase this on top of the latest changes. That's a significant learning curve for a lot of people. And I think we have good documentation on that, but you have to know what exists. You have to know where to find it. And sometimes us as maintainers or some of just the people in the community, we could be a bit more helpful also, maybe just being explicit with those steps. Like, okay, can you rebase? And if you haven't done it before, look here, or here are the two or three git commands, because I think we forget how steep the learning curve is with git and a complex fast moving repository like this. Yeah, I mean, one comment here. So with regard to the first question, Daniel, I think, I mean, this specific case where you introduce a change or anybody introduces a change and you have tested that, it works. You are not making stuff up. You are sure it works, somebody tells you, like the maintainer in this case, or every viewer tells you, that doesn't work. Obviously, I mean, there is somebody is wrong here. And that's where the discussion needs to continue. And I mean, without even going into escalation, that's where a technical discussion, because the maintainer might actually not be aware or they might try and did it wrong or whatever, right? I mean, that's where, but it shouldn't stop there, right? I mean, it shouldn't, I mean, the maintainer can say it doesn't work, and case closed, we are, you know, stay become still, and it doesn't go. There has to be some interaction. And I am not sure exactly where that stopped in this case. Yeah, because that I see that happening in many board requests where there is this interaction that, you know, even the maintainer doesn't know, because there is a limit to that. To the second point, I think one thing that we need to have also in our, I think we have that in our documentation for the project roles, is that if a maintainer or any reviewer, for that matter, asks for something or gives you a minus one, they have to provide a reason, you know, if somebody dismisses a review, they have to provide a reason. There is, I mean, nobody, I mean, you can just go and do a minus one on a board request and just leave the board request without giving an explanation why you are doing that. Yeah, I see people adding a DNM do not merge, you know, because, you know, they don't, I mean, you have to provide a reason, right? I'm not saying to you, to whoever actually reviews your request, they have to provide a reason. And if they don't, they are not doing what they are supposed to be as a maintainer. So there is probably a problem of maybe we have, I need to check, we need to make sure that it is covered in the responsibilities of the maintainer or the reviewer in this case. And we need to make sure actually that all of us here and those who are not present here, that they are aware of their responsibilities. I know we published that, we put that in the documentation, but like many other things, you know, a lot of things just go into the documentation and nobody sees them. You know, I mean, not everyone just goes through the documentation every time they are updated. So we as a project, I think we need, we need to make sure every maintainer is aware of their responsibilities and rights in this case, and document also the expectation and the review. What advice do you have for newcomers trying to have their first pull request accepted? We are working on sound open firmware and at some point we had to do some work in Zephyr, but we noticed that it takes a lot for our pull request to be accepted. Luckily, we are at NXP and David helped us a lot, but for a newcomer that it isn't backed by a company, what advice do you have? Okay, okay, so I'll start. I mean, we can go to others if they want to add. I mean, we have, I think, a very good getting started guide. I am saying that now, you know, it's not like I follow that or I go and make sure it works every time we change it, etc., but it has been evolving over time. It went through a lot of iterations and we have people actually go and test that from time to time on different environments to make sure it works, especially when it comes to setting up environment and so on, right? And so we have some documentation. Right now, actually, something that we added recently, Benjamin, you know, our community advocate, developer advocate, actually added like a CI or GitHub action type of automatic response to newcomers, where it actually, right now it welcomes and there's a link. We actually talked about that yesterday and that we want to expand and add like, you know, all of the important links in this welcome message so people know exactly where to go and look. And I think if people follow, if new contributors follow these guidelines, they should go far away with their contributions. There will be always issues. And that's where our CI start tries to catch all of this, like commit messages, sign off, you know, the coding style and so on. And that's, I think, also, due to some recent changes that Carlis here introduced, where it actually shows you in the GitHub code, where the problems are, that actually helps a lot, you know. But then there is a limit. I mean, if you have never used Git before, I mean, that's going to be a challenge, never mind what. Yeah, so that's where we are. I just thought I would also add, if you are ever unsure of your PR, whether or not it's ready, you can always submit it in draft mode. And I'd be more than happy to provide some feedback on the initial draft of the PR before it's marked as ready. And I'm sure that any of the maintainers are fine to do that now. And also open up Discord. We're all on Discord pretty regularly. And there are multiple channels. So if you have a PR that's targeting a specific area, you can ask the people that are involved in that area. Does this look okay? Is it in draft? Is it ready to publish? And so on and so forth. There's so many. Exactly. And I think that's a problem. Okay. So just to add to that. So entering Discord, I realize now that that's a problem, the channel jungle we have, I think we have to do something about that. I agree. But the problem is when you're in and you've been in for a while, you don't realize, because you don't know them all by heart. But the advice for me that I would give anyone is to persevere. Just don't give up. And in the sense that at the same time, obviously, you have to leave some time before you hammer someone with the same question multiple times, because you have to wait for someone to respond. But the thing is, some people ask and then disappear. And that really is not productive, because you might be unlucky enough that you post a question on Discord or even on GitHub. And for whatever reason, the people who usually would have answered this kind of question were either absent or just a missed notification. That happens. So you have to ask again, maybe wait a week or three days, ask again. And if really, really, really you cannot get it, then try another means like the mailing list. But the point is we have multiple ways of asking for help. And it's true that sometimes the request, the question fall through the cracks. But we have another, yet another mechanism so you can use them all. Have you persevere while at the same time being careful not to insist too much? I think that's, you'll get your PR in for sure. And finally, submit an issue as a bug. Again, as Scarlett said, there are so many ways to communicate. Maybe that's a problem because none of us can follow all of these. And that's something we need like the Discord thing. I, myself, I mean, I follow one or two and people go in the different Discord channels and ask questions unless they tag you directly. You don't see these, right? I mean, this is really too much. Yeah, yeah, nobody can. And the problem is there is like, I'm not really pointing at anyone here. If you ask a question like in general, because people will start pointing you to other channels. And that's where it gets lost because, okay, you pointed to this channel, which is very specific. And, and, but, you know, it might actually be wrong or not everybody's monitoring that. And so there is, there is this, the, yeah, we need, we need to do something about. Yeah, but this is too much management. And then you have to manage 60 channels and making sure that the right name is there. And, you know, I mean, at this point, yeah, well, yeah, we can also use bots, but again, this, we are just making it more complicated, I think, yeah, just file a bug. Yeah. Yeah. If we remove some of the channels, then people will complain that there's too much traffic on general specific, why do I, why do I get spam with a thousand root questions? So that's the problem. It's hard because it's hard. It's hard. And I think that's where you also need to think about, okay, use, use the GitHub issues. Yeah. I mean, this is something that gets triaged, right? So, I mean, if you actually have a problem file, file an issue, right? I mean, the discord probably we need to define. It's a discussion. It's not, it's not like for filing bugs, you know, and things like that. I mean, we need to come up with something. You want to say something? You know, just quickly, maybe to echo the comment regarding starting with draft mode, don't feel like the first PR has to be like hundreds of lines of code. You can make it like really, really small and take it from there. Right. Like that. Does that too? We have a few questions there, but also an answer if you want to answer. Yeah. Okay. Yeah. I'll pass it to you as well. Yeah. I just want to add, yeah, I think I did. Honestly, starting small is really good when you're a new contributor. You know, if you, if you open a smaller PR, I've seen it happen, like someone who is a completely new contributor, open a small PR, you did an excellent job responding to them and you responded to them quickly. You walk them through, they had a couple of compliance issues and I think it got merged maybe less than a day because they were responsive and you were responsive and just work through the issues. Hey, Daniel, can you, can you give the mic to Benjamin? Benjamin, stand up and introduce yourself because you are going to be really the target for all the comments. I'm Benjamin Cabee. I'm a developer advocate at the Linux Foundation. I actually do maintain the documentation with Carlos and, yeah, look after, I mean, yeah, first time contributors like I'm listening for sure. You wanted to, just a quick comment. If you're, if you are a first time contributor, they're probably one of the best ways to get your PR in a state where someone will look seriously at it is please just pay attention to the CI because we're a fast-moving project and there's, by necessity, there's a lot of requirements that we need, good commit messages, proper subjects in those commit messages, the coding standards have to be met and maybe you haven't because you're new to the project, you haven't set up all the infrastructure on your local PC to catch these things before you, you push that out but pay attention in that first hour after you push out your PR, look at the CI, look what fails, fix that, push that out and otherwise it's just going to give people a reason to ignore your PR and they're generally quick and easy fix and there's helpful messages to say what you have to do about that. So definitely just keep your eye in that hour or two after you make your push out to the CI which catches a lot of these things and you're not you're not going to be used to if you haven't committed to the Linux kernel or something you might not know the expectations around what the subject line is and the sizes so just that's a great way to get your PR in a state where it's more likely to be reviewed if there's not all this low hanging fruit that people can just don't know not going to look at this because of this particular issue. So watch the CI. We have a few questions there. Yeah. Thank you. I just checked the good first issue on the GitHub and I see that there are many issues that are two, three, four, five, seven years old. Is there still a sense to work on those? Is it still a good idea to start with those good first issues? That's a very good issue. That's actually a perfect question and I'm going to say yes because if it's still there it should get knocked out out of the park really fast and also just say I'm talking about POSIX on Thursday and I'm going to have a list of about 21 good first issues that should be doable in a couple of hours. So please if you're interested in POSIX very easy stuff. Are they marked? Are they marked as? They will be. They will be okay. No, no, no, that's basically means if you are interested in contributing to Zephyr and yeah it's something that you can take like it's a covariate bug or if it's something easy. Yeah, I don't think that we are following that or like we are not consistent about this and whatever is marked as good first issue is probably still or old or not relevant anymore because of the backlog we are talking here about enhancements most likely yeah not bugs in this case because you are talking about six, seven years that's like very old. But yeah that's actually a very good, is anybody taking minutes? So yeah we have a recording. So that's something we need to figure out. The good first issue is probably something we need to revive and make sure it's documented and it's also clean up the backlog. Go ahead. Another good idea is before you start working on an issue in GitHub if you're not the maintainer of the given subsist and reach out to that maintainer to see if it's this real and do you have any guideline for me for how to address this and how to approach solving this issue. There's a question over there. Yeah, here's the runner. Yeah, I want to tell something. Can you guys introduce yourself to us? Okay, I'm sure I think I have collaborated with Robert Luwas on the TCP stack recently and I have gone through the learning curve myself and I was fortunate that Robert was patient with me and directed me in the right directions in order to make me into someone who can contribute and to end it a little bit positive. I want to ask the maintainers who is it doing as a day job maintaining Saphir? Among other things. And maybe you can tell something what you like and especially the ones that are not doing it as a day job, how you combine it? Yeah, I do not do that as my day job. Well, my day job is working with Linux, so I have all the interest in having Linux in a way that I feel like it's workable with, so I try to like split my time between my day job and also some hours of well, not many hours a day doing my maintaining job because I care about the project. Okay, so like I want my day job to be easy, so I want my playground to be like up to the task and up to the job and this is why I care about the project. This is it. Anybody else? Johan? Maybe something what I do not like, the new boat because I get a notification on if I have to take a box or a pull request if there's something new that it's just for me, unnecessary step to look at the email. Louder. The new boat. Yeah, that's what I do not like. Yes, no. Why? But you are not a new contributor, so why do you care? Yeah, because it's more of work for me as maintainer to catch up with emails because that will generate a new email on image if it's new issue. It will generate new email, so it's the second one and the same for pull request and it's sometimes confusing here because I would open the pull request. If I had looked at the pull request, there's nothing new and the boat is like confusing for me. If I got another email, is there something new and the pull request, that's just the time. Yeah, but what's the difference between getting 2,000 emails a day and 2,005 emails a day? No, not 1,000 emails a day. You can filter for issues and then it's much less. So part of my day job was LTS to your release manager. I was fortunate enough that Meta was able to give me eight hours a week to do the LTS release. But on the other hand, I also maintain the POSIX, FPGA and then I contribute to C, contribute to C++, contribute. I manage Thrift now. I do way too much to be honest, GPIO. Gosh, everybody wants to talk about LTS. We know, we know, we know. Actually, we're always looking for help. So I think really in the end, so I feel like I do my maintainer stuff after hours, which really cuts into family time and that sort of thing, which is it eventually becomes way too much to deal with. So I try to put a cap on that. But one of the nice things is actually, I would say before I'm a maintainer, I'm a user and a contributor to Zephyr before I'm a maintainer. So if I need to fix something, I put up a PR, right? And then I get my fellow maintainers to review my PR. And aside from that, I mean, as a day job, if something for my day job helps my company, then I will for sure not hesitate. If we're not infringing any IP or anything like that, then if it helps my company, I'll make a pull request. But aside from that, a lot of after hours stuff. Anyone else? I think we still have a lot to find. So I think one of the things I've been a maintainer in the Lenox kernel in the past, been a maintainer in different parts of Zephyr and so forth. And I think there's a couple of different things I see. So one is it's a career opportunity, right? You see the number of people at this conference, you see the number of, a number of us have been involved in this project for a long time and have seen it grow through that, just being an open source project and the beauty of that I find of an open source project in, there's a number of people on the stage or up here that they're competitors, right? But we work together on something and that's really cool. It's cool. I know for a lot of us, after COVID and everything, it's an opportunity to see people, you build friendships. And that's not unique to being a maintainer, but it's definitely something that's an aspect of being part of the project and things that I've found in my career through this and a lot of the opportunities I have that is, and I know I've gotten jobs where because people know and have worked with me in the community, there's no interview process because they already know me, right? It's already, you already know and you've already been interviewed. People can see the code you've committed and contributed. It's the best resume possible in a sense. So yeah, and I know a lot of people in here and a lot of the companies involved are always looking for more people to help and contribute as they grow their products and support for what they're doing with Zephyr. Yeah, I mean we see that. I'm not following this discord channel in this case, but we have like hiring and I mean it's always interesting to open this and see that people are really looking from the project. You want to say something there? I was going to repeat basically what Kumar said. I was going to say that I've been working in open source for a long time, probably 15 years or so, more or less often full-time, but I was going to repeat basically what Kumar said was if there's a question, how do you balance this with your day job? Well, I initially got involved in Zephyr just because it solved some problems I had and it wasn't my day job, but by getting involved and starting to push out code and engage with the community, it became my day job when literally Kumar hired me and into his team. So it depends what you want professionally, but getting actively involved in open source, particularly a project like Zephyr, can be a great career move. It gives you a visibility that you might not have somewhere in an individual silo, so maybe that starts as something evenings and weekends because it scratches the right itch for you, but that can very often lead if you demonstrate competence, commitment and you stick around for a while, that can lead to other opportunities. Obviously there's no promises, but generally I think in our field it's a lot of just word of mouth when it comes to recruitment and opportunities and projects like this, if you engage, can lead to interesting things and don't be afraid to get involved. I really do think Zephyr, I've worked on a lot of open source projects and with a bunch of different communities, this really is a great community. We're not perfect, but the people are genuinely open, they're helpful, they're willing to sort of put an effort into getting people up to speed. And even maybe something like ending up like a maintainer seems crazy to you, but don't be afraid of that. In a sense, you don't have to be some super expert in a field. Often becoming a maintainer can be as much to your benefit as anybody else. It's not just all hard work, it is hard work sometimes, but it's an amazing opportunity to learn as well. I don't feel like I'm some amazing 32 bit arm expert, but because of taking on that maintainer role just because there was an absence there and somebody needed to do it, I wouldn't have naturally pointed myself out, but I've learned an enormous amount of things about the arm architecture and I've worked with it for 20 years because of having to sort of take on that maintainer role and it can be a great career opportunity too, but don't be afraid that you have to be this brilliant person who never makes mistakes and always terrified of screwing something up in public. We all make mistakes and in general this community is extremely receptive, I think too, and open-minded and that's not a given and some of us have had bad experiences maybe in other communities, so I'm really proud of what Zefra is as a community and I'm very grateful to sort of be able to work with people with this kind of personality and technical caliber. So do we have love? That was long, sorry. Is there a question there? Okay, let's... Hi, I'm Juliana. I'm contributing to Zefir. I have a question regarding the repos. Why do we have so many repos in Zefir? I will give an example. Recently I'm working on an open AMP and lead metal and I was wondering why do we have a repop for open AMP in Zefir? Why don't we get the one from GitHub directly? So this is just an example. I know there are others. For the HALs, I understand. They are related with Zefir, but others I don't get it. Maybe I missed something. Yeah, so okay, so the answer is for just to make sure that in the future you can always go back in time and check out any version of Zefir. If we put in our manifest, if we point directly to open AMP slash lead metal, what happens if in two years down the line that repop is deleted by whoever maintains it now? So that means that you could not go back in time and update because that would fail, right? You could not go and check out Zefir, I don't know, 2.7. Let's play that way or 2.8. So that is the reason. That is the main reason. That's for open source projects that we fork into the... Well, that's one reason actually. The other reason is that in maybe not the case for open AMP and lead metal, Carlo probably knows, but in many other cases we have patches on top of that. Because not all the changes that we need in order for that open source project to work well with Zefir can be upstreamed, not always, anyway. Especially there's the factor that when you have a Zefir module, you need that Zefir slash module dot yaml, right? And that file, not all maintainers of other open source projects are receptive are willing to take that in. So in some cases we have no other choice but to fork it. But even if they take it, even if we have zero patches on top of the fork, the reason, the ultimate reason is just to preserve it. It's not about deleting. It's not about deleting. I mean, it happens a lot that somebody bushes something wrong. All of a sudden your history is bad and then the commit we are pointing to Yeah, deleting happens as well, but it's not limited to that. Yeah. But I want to answer that. I want actually to address the first question, which is the how come we have so many repos? Because we had this discussion today. And guys, we had we had this discussion today. And since we are all traveling, and, you know, sometimes, you know, you, you, you have to check something out. You have to fix a bug. And you're in a hotel room with 3000 other people trying to download something. Good luck with that. Yeah. Yeah. I mean, this is, this is, this is in my opinion, especially, you know, for me, I mean, it never made a difference because I'm, you know, involved in so many things as stress or trying to be can choose which module, etc. That will just not work, right? But I understand that if somebody's interested, like, you know, with in one vendor, you know, and I don't, I am doing extensa, whatever, or I'm doing arm with NXP or with SD micro and nothing else. I always built for this same board. I don't have to go download every other hell. I don't have to go download every other, you know, third party library like open thread or TensorFlow or whatever. I mean, this, we need as a project, we need to find a solution for fixing this problem. And this keeps coming up. This keeps coming up. And we definitely, yeah. And actually, I was, because I was waiting like at least two hours tonight. Yeah. Yeah. Tonight at 2am waiting for something to download 2am even. I just wanted to, and yeah, we need to deal with that. I just wanted to quickly mention that we have two new maintainers that walked in. So I'm going to let this gentleman ask this question who's been waiting patiently. And then maybe we can get the two additional maintainers to introduce themselves. Thank you. So I'm Mark from Expressive. The question is, what general rules or approach would you suggest to vendors to speed up and or smoothen the development to mainline or to Vanuva, Zephyr, avoiding fork like Nordic does? Okay. Thank you guys. My name is Rodrigo. I'm from Brazil and I'm maintainer of Zeebus. I was talking about that in the other room there. Sorry for the delay, but I'm here and it's a pleasure to be here. See you and see the faces. Yeah. Because just names. There's Marty. Hi. My name is Marty Bolivar. I maintain device tree and west. Glad to be here. So do you want to address this? Yeah. So in general, so if I understand correctly, just not if that's you asked what's the advice not to have to fork, right? To increase, sorry, increase what? Oh, okay. Okay. Right. Right. Okay. I see. I see. I see. Right. So the answer to that is getting involved more with the more people you have involved, the more maintainers, the more influence you have in the project directly in direct and influence basically is achieved through contributions in this project and in most reasonable projects. So that would be my direct answer is get more involved in the project. Obviously, that's not always possible because that requires manpower, requires hours of engineering, right? But that's really the answer. If the story about having a fork or not another fork, it's a bit different. I talked about that in my talk today is that the reason for having a fork is not always that you need to have changes that are not present upstream. You need to make change. Sometimes you just need them fast and you can't wait for the review process to complete in upstream. You have to ship your own SDK or your own fork of Zephyr and that's why you basically take them from the review process, take those changes, cherry pick them into your own fork, ship them and then later you finish the review and update the fork. But how do you actually maintain or guarantee that it's going to be? You don't. So I got this question exactly today usually. So we are very careful with that. So when we come to this, if it's a small fix that we know it's almost certainly going to go in, no problem. Just cherry pick it and wait. If it's a substantial new contribution, subsystem, API that they don't share, then we try our best not to ship it until the PR upstream has reached the maturity point that make us confident that will not be rewritten. That's the answer. That's the only way we've dealt with this so far, mostly. I know Espresso is kind of an exception because you're already quite huge. But for other companies who might not be doing Bluetooth or something like that, the best solution is a module. Inside of a module, you can create your own driver tree, your own includes, your own CMake extensions, your own SOCs, boards, literally everything. And it mirrors the directory structure that is in the Zephyr source tree. So, and there are a couple of integration methods for that that are available online. But that is by far the best vehicle to scale your Zephyr code is the Zephyr module. Because you can maintain that on your own Git server internally, if you like. It doesn't actually even have to be Git, if you want to know the truth. But that is by far the best solution for smaller organizations. So I think one thing for hardware vendors and so forth is, and it's true for I think most things really, but trying to keep PRs and changes so if there's a new SOC you're adding support for, having that change be as minimal as necessary as the first item. So I know, I know I probably commented myself a number of times on PRs and it's, I don't know if we've documented this well, we probably don't somewhere. But, you know, where a vendor will come in and they'll contribute, you know, 10 different drivers that are not necessary to just like get hello world working on the board, right? So it's like, you know, the base SOC code, maybe it's a UART, some GPIO pin, and the board. And so that way it's, again, that idea of the smaller you can make that first PR, the quicker it's going to get reviewed and accepted. And then also because otherwise the bigger it is, you know, then it's like, okay, these other subsystem maintainers have to review it, right? So there's a number of things there where, you know, as new SOCs and boards are getting supported, trying to keep that as small as that minimal, you know, PR as possible, because then it's a lot easier for the maintainers to review quicker to get in and so forth. And then I think kind of things like on hows and so forth is, you know, trying to keep, you know, sort of see how, you know, other vendors have done things, you know, how, you know, how the driver models that we have are functioning. And if something is, you know, you know, if it's like a big impedance mismatch, then that's going to be a quandary, right? Because it's like, Hey, we've obviously supported, I don't know how many SOC architectures and vendors and so forth with the various driver models for at least the base, you know, the base typical, you know, UARTs and spies and I squared C's and so forth. So we know that that the driver models there are highly flexible and can support a lot of hardware. So if you come in and for some reason, the way your HAL is or so forth doesn't conform, we're not likely to be, you know, highly conducive to wanting to change what we've been doing and has shown to work for the vast majority of everybody else, right? So that's something that you kind of have to recognize you're the exception as opposed, you know, coming in as, you know, in that case. Okay, so I think thinking about it a little bit and looking at Mordek and Espressef, I mean, probably that's an exception to many other vendors because you are providing more than just a HAL and SOC support. It's more of an ecosystem or SDK in your case, in your case probably as well, you know, with, you know, more than just, you know, give me the basic to run a board. We have Wi-Fi, BLE, you know, all of this, you know, so and that's where it becomes tricky. I don't think you need to fork anything for supporting the basic hardware. It's more about integration and support like for, you know, bootloader, how do I use the MCU boot, how do I integrate Wi-Fi, how, I mean, a lot of things that would probably need a lot of interaction with different areas to get it all done in the project. And some of these areas and that's actually where it's become tricky and goes back to what Kumar has said. I mean, whatever, there will be things that will be very specific to you or to a specific vendor that it's not really interesting for the project or it's not generic enough to be added to the project. And this is like the type of thing probably that you need or we need to figure out how you maintain that out of the project. I mean, if there's a case probably by providing like the necessary hooks in the project and then you have that as an extension, right, but that's, I think there is no escape in this case because you are going to have something unique. That's how you are going to be selling products. And that's how, you know, you differentiate from others and that can't, can't always be in Zephyr. So either a fork or figure out a way how to build that on top of Zephyr using some extensions that and that's how you can go into the Zephyr project and propose something that would allow you to implement something like that outside without forking basically. Yeah. This question has two viewpoints, a user perspective and vendor perspective. And what's good for vendor, it's not always good for users, right? So that's, yeah. Just, I wanted to add one last thing to that and that is forking and changing Zephyr entry is by definition, technical debt and a module allows you to avoid that technical debt upfront. Otherwise, you can end up paying for that later with interest and the interest accumulates. That's just my thought there. Okay, so my name is Florian and I have been contributing quite a bit over the last months and I first have to say that is it working? Yeah. Yeah. Positively, as yours also said it, I think I have done a lot of work on different open source projects, but it has never been so fast to get so much in as in Zephyr. So thank you very much. I have to name Robert Lubos as well. He did a great job there. Yeah, really. A bet. But also others. I mean, Chris, you see, as well, so I got really a lot of support really. But as a bypass as somebody coming really from the outside as not being linked to any vendor, of course, I'm also seeing some first time things that you only see when you enter project. And one thing that it came up and it fits well is we do have, especially in the wireless area, some APIs that make it hard for first commas to not first commas like me, but vendors to provide their own stack, because maybe the APIs are not easy for others to implement. And that's especially in the BLE and open thread area. So that is one thing that I think could be easier, not as meaning that it has to be different from what we have now, but it should be it would be great if we had a second option, a low level option, how you get into this as a new vendor with the option to do more exactly in the way that you propose to do small changes first. It's hard if you want to do open thread support right now. Yeah. And another thing I started my open source career with Debian and they have a very elaborate missing in action process, right? So it would be nice as somebody who would it's you would need a job board if you want contributors, right? You need something like another state of your maintainership, which is orphaned. So somebody coming from the outside could just look and say, oh, look, it's orphaned. I can apply for that job because I, for example, wouldn't know where to start, right? Yeah. And then one last thing very related to the first point. I think this is because it comes over as if it was a problem to have that close vendors. But I think it's exactly the reason why I got so much support because I think many other open source projects, if you ask how many maintainers do this as a day job, you won't get so many hands, right? So it's a big advantage on the one hand. But on the other hand, I think if the same person is doing the country or the same vendors doing the contribution and reviewing it, then you're not having a four eye principle anymore. And there are areas you said, okay, it's good if you have many maintainers in there because you have a lot of power, but that power can also be abused. And there is a certain, I think it would be a good idea to have a four eyes principle in the sense of you want to really be sure that what our API is at least, not the drivers, et cetera, that's low level stuff. But the API is should be reviewed by when there are changes to public APIs exactly in the manner that you said, oh, it should be useful for the project and not just to because as a vendor, you have a lot of management pressure behind. And I see there's also some divide between the technical people who would love to have it better and the pressure that comes to get it out on the market. So my full understanding for that. Yeah, no, that's actually a very, very good input. I mean, this is the things that you mentioned here, things that we have been thinking about. I personally have the four eye principle. It's definitely something we need to look at enforcing in the project right now. Because I feel that it is right now, at least in the Zephyr project, it's very easy. And that doesn't have to be intentional. I mean, the batch is submitted by me, reviewed by somebody who sits next to me. That's not the case. I have been working remotely for 20 years. But you know what I mean? And then merged by me. And that just doesn't make sense. I mean, we need to figure out a way how to avoid this. So we have areas with maintainers or collaborators just from one vendor. So basically, you get basically the maintainer approving a contribution by someone from the same and that can and merged by the same, you know, somebody from the same vendor that again, it doesn't have to be ill or how do you call it bad intention or anything like that. But a lot of there has to be a review process for that. So that's actually a very good point. The other one, you had another two good points there Oh, missing an action, missing an action. I like that very much. Yeah, because I didn't like orphaned. Because when you put orphaned, that means this thing, nobody cares about that in them or it's, it's non functioning. Yeah, yeah, exactly. And missing an action makes excellent. We need to think about that as well. Yeah. So I think we have this and we need to clean it up some to kind of what Anna said. And I it's probably not published well, but I think in the maintainers file, we do have a state that is orphaned today. It's called mis, miscellaneous or whatever. Yeah, I don't. Yeah, we don't have the orphan. Okay. But, but we do need to be better about sort of, you know, making it clear, you know, so obviously there's been different things, you know, whether it's like the, you know, we mentioned earlier, the, you know, first time or new first time issue or whatever we called it, you know, so there's things where we've tried to over time. And, you know, again, it's, it's the amount of bandwidth for everybody to work on these different things and try. So, but it is something we should definitely work on on that side. There were two other things I wanted to mention. So one was just real quick on the previous comment. One other thing I was going to mention is as vendors come with their code, one of the things that the project has been very clear about is license, right? And so if you are bringing a repository that isn't an OSI approved license or as not, you know, that has mixed licenses, it's fine if they're mixed OSI licenses, but that is going to be a non-starter for the project. So that is another thing just for a how vendors who maybe want to contribute to Zephyr if they're wanting to maintain sort of a how layer or so forth. If that how isn't, you know, one of those licenses that that's a standard license, that that's a non-starter for the project or and not yeah and non-copy left because obviously the base license for Zephyr being Apache. So just wanted to add that just, you know, came up. I think the other sort of thing that and maybe to kind of clarify, which is I think it is a fair point that there are probably hardware abstractions in Zephyr for devices that are more complicated and Carl's going to try to talk better to Bluetooth, wireless, where we need more vendors to come in to help, you know, maybe adjust where that line is because for those type of devices, they are more complicated and we need just, you know, like anything having more voices, seeing like, Hey, this is where this hardware vendor is, this is where this hardware vendor is, you know, so we can better create the right abstractions or improve them. And so some cases, it's going to be a bigger effort, right? So some devices, I think we, you know, you are, you know, we kind of understand and so forth, right? But there may be others that are that are more complicated that we do need more voices to help improve where those lines are. So actually just directly related to that. So I know which I think you I know which PR you are alluding to sort of and yes, we know and we had the meeting about that internally, but you have to you have to very mind we integrated open thread with refer a long time ago using the 15.4 API from we've you've been improving that over time and then the changes you're proposing are substantial. So yeah, so we need we need time to digest second. Yeah, yeah, yeah, exactly. Yeah, just just to know that, you know, there is no vested interest nowhere here from the maintainer well and where to block or prevent you from it's just it takes time to find the solution. And, you know, we are working on it. Thank you. We try to at least. I also just wanted to mention in terms of the maintainers file, if you see a line that says odd fixes, that means we need a maintainer for that area. And I don't know if there's a hard limit, but nominally, we should have three collaborators per area. Yeah, I mean, you can have as many as you want. And the more people that are collaborators, the more reviewers we have, which means PRs get merged faster. And it goes to the kind of the four eyes thing, right? Yes, absolutely. Right. The same person who's adding code isn't the one reviewing it because there are more people to review it in those cases where there's a maintainer. Okay, since since we are approaching, like, I mean, that has been actually very helpful. Yeah. I mean, let's, you know, be a little bit productive, get results out of that. There have been actually a few very good suggestions that I think we need to take like to the different forums to, like, the four eyes. Let's let's make that official. Yeah, because I really don't like the fact that it is happening in in front of our eyes. It happens all the time. And you can, we don't have any way to prevent that. Yeah. Again, this is not something that is done being intentionally, but a lot of things can go wrong if it happens this way. So there are a few things that missing an action fixing the maintainer file, and so on and so on. So I'll try to write this down and we'll take it to the right forums. But this has been a very good discussion. Are there any anything else from the maintainer themselves or from you guys here, the audience that you think this is like really like the make it or break it type of thing that we have to change to stay successful as a project and to stay healthy as a project, besides additional things that you think we need to improve in general to make it the developer experience better and as a project also to move forward and not stagnate on because of these issues. Yeah. Go ahead. Hi. Hello. I'm Ken Miller. I'm relatively new to Zephyr. I've been using it since around January. So maybe here's some feedback from me just sort of as a user and then contributor perspective. So I initially started this to build a small ultra low power device as a sort of add on smart murdering solution. And so I came into it when in one of the decisions I made to choose Jeff as a Zephyr was the documentation and of course the cold with the code quality. I came from an embedded Linux background. So a lot of the stuff made up just made sense to me reading the code and you know stuff like device tree. And so I'm really appreciative about the documentation and however there of course can be things that can be improved. So the first step for me was I'm looking, okay, this SOC is applicable to my use case. What is Zephyr? You know, how has ever support this and you have the list of supported peripherals and it's like, oh, it does ADC. It does subgeekers radio. It does everything I need. SPI squared C. But then you start working with it and you notice there's these little gaps that are missing such as one thing for me recently is I'm using the STM32 platform. I have some PRs that have been merged for STM32 WL and things like low power management of course. So I look at the device tree, the first assessment is, oh, we have stop 1, stop 2, stop 0 through 2 mode support and there's a sample for standby and shut down stuff specifically on this platform. And I love the samples by the way. It's fantastic. It's for me as a new user, one of the best ways to get started in understanding how a subsystem, how a driver works, really good stuff. But then diving into the lower end stuff, I noticed, oh, I'm trying to use stop 2 mode and I get deadlocking when I'm doing that with the ADC or with SBI for the subgeekers radio on the specific platform. And so I've been sort of, you know, spiraling in this vortex of, okay, I'm going to fix this now. And I have a PR currently for the STM32 peripheral reinitialization sort of on the going. I'm trying to collaborate with Flavio, but I think he's in the different, he has a different talk right now. Anyway, so maybe something I think in an ideal perspective would be or ideal solution in the end would be you have some sort of documentation or template out of generated from device tree that you can then use to sort of give the developer or at least the vendor in this case, a template which they can expand and sort of, you know, check boxes saying, okay, I squared C works with all these low power modes or other little details like the UART, for instance, on STM32, STM32 has a general UART driver, but there's some little bits and pieces missing there, such as nine bit database, a very specific low end stuff, right, that, you know, obviously most people won't care about. But if you're, you're a developer trying to implement something very specific, you come in, you don't realize this into the end of your, you know, knee deep in the code, you're like, Oh, I need this support. So I guess I'm going to, you know, I'm going to write it and add a PR for it, which is good for the project. I like doing that. And it's been awesome collaborating so far. But it's just unfortunate that you have to learn this after the fact that, you know, when you're, you started adapting the project, sorry. I just for sure wanted to mention the driver specific test suite. So I squared C, for example, there's the driver test drivers, I squared C test suite. Anyone else want to take a stab at this? Yes. So indeed, this is something that's not easy to document. And often, we get, we get questions from, from users on discord. Hey, is that supported? And is this feature supported on, on this part, on this part, on this part? And because obviously, features are developed steps by steps. And it's, we're taking contributions that sometimes add a new feature. But so it will bring the feature in the first step. And so this is great, but the feature is not completed. And so in the end, the status is something uneven that can appear unfinished and complete. But this is the way it is progressing. Hopefully, years after years, the picture, the picture is better and better. But there are new gaps occurring. And yes, it's difficult to, to, to, so this has to be documented. This has to be clear to users what is the current status on such features and such stocks and so on. And I don't have quite a good way to, on how to, how to display that, how to, to document that. So this is a good point. This is a part of the documentation that we need to, to improve. So we have a part of further documentation, I think on Tuesday. So hopefully this is a, this is a good point to discuss. Okay. Yeah, it's hard to come up with a list of features that don't work because we don't know that they don't work. But if you find an option driver and some specific features that are not implemented or doesn't work, if you're under the impression that the driver is maintained, especially by the vendor, probably the best thing to do is open an issue and ask how to implement it, or if you can implement it yourself. But yeah, it's a big problem. But it's part of what you have to do for using something very specific on a, on a real time OS that tries to cover as much as possible from a broad number of different microcontrollers from different vendors. Like the, the, we can only implement the minimum stuff for everything and then try to expand on the specific platform as needed. Yeah. Yeah. But it's not as unintentional that some features are missing. It's just that, yeah, no one needed it. Yeah. Okay. So any, okay, we have a question. Yeah. It's the last question. Yeah. Yeah. Last one. Martino from Arduino. And I wanted to ask you one thing, one single thing about the discord thing. I have quite an experience in open source communities and stuff. And one of the things that still works is just searching on Google for your issue and finding it and discord make this thing impossible. And this is a big issue in, we saw it in our community. And I strongly suggest that you, I don't know, gather some ideas on how to mirror it somewhere or because this information cannot get lost this easily. And I don't know if you thought about this. And it's not just about the fact that it's fast communication. It's very nice. It's also very overwhelming. And the quality of the information is much less than it used to be on forums and things that are meant to stay there. And on the other end, it gets lost. It's unsearchable. And I completely agree. And by the way, before discord, we used Slack without archives. So at least we have some history. Before that, we didn't have history at all. And I think we need, at least as maintainers or people who are responsible or always monitoring some of the chats that if a question comes, the first thing is, is there an issue? Did you file an issue or open an issue? Instead of having logs and things that get lost and not, because actually, this is what you just said. I mean, I was thinking about it last night while I was doing my presentation this morning. I was searching for something that I remember from the history. And I said something and seven years ago, an issue was opened. And I was able to go there and fill a slide from this content, right? I mean, this is, this is, I mean, this is really the power of search, yeah, with a Google or something else, right? So I think you are raising a very good point is that we need to start pointing, instead of having the bug resolved or the issue resolved in GitHub, sorry, in discord or in a chat, it's really, we need to encourage people to go open issues. Yeah. Yeah, all discussions. Yeah, but it's not as convenient. I mean, I mean, there's a difference between searching and getting the results and then going. So I think we need to discuss kind of in the process, meaning, you know, how we deal with some of this and things that may be shift to issues, shift to the discussions, get the things and start trying to enforce that behavior, you know, by the maintainers in this court and so forth, say, hey, please move this over to discussions. I would say, I mean, it's actually, it's going to be the same. It's a discussion. It's not an issue. But at least it's archived. And it's not real time. And it's going to be, your, your discussion is not going to be, there is no interference with others asking questions. And then you have no idea who's, who's having the problem, because you are using one, one channel for this, right? Okay, so two minutes. Yeah, exactly. So sorry. Yeah, but, but we can't resolve it right now. Yeah, I mean, no, and, and there is, there is a process for becoming a maintainer. Yeah, so we, we need to, yeah. So, yeah. Oh, okay, I have this one. Yeah. So thank you everyone for attending. I think we had lots of good feedback, very good discussion. We are definitely going to go back and, and try to address some of the issues raised and some of the improvement or proposals. And I think this format actually, I was not sure how it's going to work, but it's actually working really well. We need to do with more mics. Yeah, exactly. Or have a few fabulous running around. Yeah, it's, no, it's great. So thank you again, everyone. We are still obviously here. So if you still have questions, there is the zipper booth. You can go ask the questions there and Brett will tell you exactly or notify the people arrange a meeting or whatever. Yeah. And we all have the, I have many of them. So you will not miss, I mean, not be able to miss me in this case. Anybody who has the zipper tag and the maintainer tag, that's easy to identify. So please, yeah. Thank you again. Thank you for everyone. Yeah.