 Hello, hello, everyone. Welcome to this presentation today from the Yoctoproject. My name is Nicolas Deschanes. I'm here today with David Reyna. And we are very happy to be talking and discussing about the Yoctoproject LTS releases, which is something which has a very important event, which happened in the Yoctoproject this year. And we are very happy to be talking to you about these things. So first, a little bit about us. So as I said, my name is Nicolas Deschanes. I work at Linaro. And I'm also the Yoctoproject community manager. So I've been involved with the project and for the last two years as a community manager. David is also here today with us. And we are going to talk to you both today. David is working from Winiver. And he's at inside the Yoctoproject. He's taking charge of the trainings and the developer day. So we have an agenda for today. Before we get to the agenda, I have a couple of announcements that I wanted to share. So first, there are a few. This is going to be a very different event, obviously, for everyone, including ourselves this week. So I want to, at least, you to know how you can actually reach to the people from the Yoctoproject or people from our communities. We have many people that join us for the event. And we are going to be there at the Yoctoproject booth. So the Yoctoproject is a sponsor. So you can come any time at the booth and just come and talk to us. We also have a dedicated Yoctoproject Slack channel on the Linux Foundation even Slack channel. So feel free to just come and go out and ask any questions. We have, I mean, more than 150 people there that can hopefully help. And we are really looking forward to the great discussions on this channel this week. About the week, we have two events that the project has actually also organized. On Thursday, we are going to do the Yoctoproject Dev Day, which is like a full day of sessions and mini-submits about the project. And we have people from our communities that come and just going to talk to us about many things on the project. And later today, tonight, or wherever you are, we also are organizing the Yoctoproject BoF, the booth. And I mean, we will be here to go quickly through the updates of the project and talk about any questions you might have and what you want to discuss or what you want to know about the project. Anyway, so with that said, let's go now and talk about this LTS. So today, as I said, David and I will go through this presentation. So I will start with a quick introduction about what is the Yoctoproject and the organization and the membership. And then David will guide us through the current release process and what has the recent changes we've made over the last year in automated testing and improvements. And then I'll go back and talk to you about the background of the LTS, why we ended up with the LTS and what it is. And finally, David will come back and tell us how you can help and get engaged with us. So what is the Yoctoproject? So hopefully now, most people should know. It's a very old project. It's 10 years old, almost. It's basically, it's a Linux foundation hosted project. And it's a collaboration program where that provides all the tools, all the recipes, and everything that you need to build your own custom Linux distribution. It's not a Linux distribution. It's a toolset that actually allows users to make products or hobbies or anything to make your own Linux. Whether it's a very small Linux to a very big Linux, it can actually build anything. It started on the embedded space 10 years ago where things were quite difficult to build Linux and build Linux systems, embedded Linux systems. Nowadays, and you will see, it's used more and more outside of the embedded systems. Again, it's very important to understand. It's not a distribution. It's you don't just go and download something and run it. It's you download all the tools, all the metadata, all the documentation that you need to make your own complete custom Linux system. The way the project is organized, so it's an open source project hosted by the Linux Foundation. It was actually the first of the Linux foundation projects started in 2010. Nowadays, there are actually a very large number of them. Like most of the other Linux Foundation projects, there is a governing board which is made of companies, but also a Linux Foundation corporate members. We have different level of membership from like Silver, Gold, and Platinum. And basically, it's all the companies that want to influence one way or the other, the project. The governing board, as I say, and can, for example, elect the members of the Technical Steering Committee, which overview the project architecture and the technical decision behind the project. But it also, the board also has a say on the budget and how we get to spend the money that the project is making from the membership. So there is a large number of companies. You can see all these companies on the slide. And definitely, if you're interested to talk and discuss what it means to join or why, it might be a good thing to join for your company. We are here to discuss about these things. Behind the scenes, the way things work, most people will know the Yorker project as the website and what to do and how to build, but there are actually several teams that actually make up the project. And we are all organized around the adversary board, which is made of one person for every member company. And we organize in different teams and a couple of officers volunteer some time. I mean, it's for community, like I do myself. Or we also have another advocacy team that is actually taking care of all the marketing issues and things that we do for the project. The TSC, obviously, which takes care of the technical decisions. And the governing board, more generally, and it's the one, I mean, meeting once a month or once every quarter to talk about the general direction of the project, oppose the finance of the project, and all things related, general administration, things related to the project. And now I'm going to end off to David, who is going to talk about the current release process of the other projects. Okay, so that's part one of our trip to the LTS release. This is the second part. This is what we're doing right now for our release process. So right now we have a process of milestones per release. We're on a six month cadence. And in each of that cadence, we have in our case four milestones. The first milestone is kind of combined with the release planning. The second one is where we try to get most of the features, big features done. The third milestone is where we try to get all the working done as kind of our feature freeze. And then the final milestone is our civility and bug fixing. And for each milestone, we have the process of having a few Q and A cycle and we have a few full release cycle and releases. And we all try to make sure that every single milestone is as stable as possible so that we can then have a stable cadence as we go forward. So we release twice a year in April, October and there's three things to know about that. One is that we're very stable, very regular in our releases so people could depend on the release happening. But of course there's a tension with that release cycle in that we're always kind of missing a few of the LTSs, a few of the package updates. And so there's always that tension between trying to have something stable and complete and dependable on time, but also might sometimes missing. For example, missing the kernel LTS or GCC LTS or some of the Ubuntu 20 just came out right after released, that kind of stuff. There was always that tension between civility, time dependency and making sure we have the right set of features and everything. So let's go on to the next slide. So what is in a release? There is the main core components and that's the OECore that sounds or open embedded or base project. BitBake, of course, is our build system. Betiyachto, our release and the documents. We're very keen on our documents that go with our release. Major components, as you can see, our ABI API, the major version upgrades, all the packages, some 1,300 packages that we maintain for our cross build system. New features, of course, and long-term kernel support. New features we'll be working on, for example, the test infrastructure changes, which will be covered in a slide later. Automation changes, for a project this big, you had to have automation to kind of survive from release to release. And architectures being added and removed, kind of keep, make sure we're up to date with all the latest BSPs to serve our customers. Bug fixes, of course, issue to the after project. We have a very active bug board and bug backline and we also have a very tight integration with all of our upstream projects. Our packages are, of course, the open embedded. We try to work closely with the other projects that make sure we have the greatest and best, at least most up-to-date content for our release. The stable release content, let's just talk about that. So when we release, on the cadence you saw before, every October and April, that's our initial release. So then we go into stable releases, the point releases, dot one, dot two, dot three. And in those stable releases, we cover, of course, security and CBE fixes. Those are automatically go in. Try to make sure we have all the CBEs for all the stable releases that we maintain. We also try to keep up with bugs. So we have the bugs found during release by our customers, by our commercial partners. We make sure to get those fixed so we have stable code. Certainly the new distros to try to keep up if Ubuntu or Red Hat or Fedora or any of those come up with a new platform. We want to make sure that we cover it. Bug fixes for version upgrades. So that's where we fix what we're supporting. And the unacceptable stuff is, of course, the general version upgrades and the new features. As much as we like to bring new features into existing stable releases, we kind of resist against that because we're kind of always moving forward. We want to make sure you don't destabilize the stable releases that people have based our products upon. So strict backward policy will always push the master first and then we pushed on to the stable releases. And same testing as a regular release. So every time I do a point release several times a year, we make sure we do the full QA cycle, full review cycle, full document update cycle. So that goes there, going on to the next slide. Stable release challenges. Typically, we maintain things for seven months, each of the stable releases. We made this first for up to a year for each of those releases. And this is all done, of course, and we're a community, a volunteer community. So it's all in community time. And we thank our community for supporting and backporting all the patches and maintaining our releases. And this relies on our member resources. So they all work together to try to keep everything up to date and all the bug fixes and CV checks and everything all put into our release. Going on to the next slide. So automated testing improvements as part of our strategy for making sure we have a strong release and we can have as big a feature list and big a package matrix as possible. So we have invested a great deal of money and time into our order builder. 25 builders, 12 post distributions, plus our top of that. And fairly, we made a lot of investments in 2019 to kind of monetize all of our builders. And again, this is how we can maintain our huge matrix of packages, posts, distributions, features, documentation and all that. Major improvements these last two years include the need for a manual test to reduce the need for manual testing. So we have invested greatly in P tests on ARM 686 with 60 pieces of software, as you can see. We've also maintained strongly the LTP and LTP process tests and test reproducibility for a tool chain and minimum images. And of course the GCC, the whole architectures across our main architecture line and we test 1.9 million tests in every eight hours. And we're pretty proud of that. That's a lot of infrastructure we put together. There's also just mentioned a couple of technologies we've added to the October project this last year and that is the binary equivalence and the hash equivalency. And with those that is certainly for our customers or for our users to be able to have reproducible builds and the hash equivalency is a way to actually enhance more efficiency with our state cache. And that investment also helps us with our iMate testing. So we get to eat our own dog food and enjoy it too to really increase our efficiency and coverage. So I'm gonna go back to Nicholas. Okay, thank you David. So now that we discussed and we've talked about how we have made releases in the project for the last 10 years and it's actually quite interesting to see that we have not missed a single release in the last 10 years. I mean, it's been really good for the October project. So now the LTS is something is a very, there is a very interesting use case behind the LTS and that's what we like to talk about is what the membership and how we can actually make such drastic changes and some big changes in the project which is very interesting. So why it happened and what happened and how it happened basically. So what we've heard from some users of the project is that the six month release cadence which it aligns very well with the pace of open source development which means that it's very easy to have like a very up to date systems is actually upgrade to every release every six months. You always get the latest version of all the packages and all the Linux open source components, which is great. However, sometimes and in some specific markets, especially in the embedded space, six months being able to upgrade your system every six months was actually too difficult. What we've seen and what we have observed is that people were actually not upgrading and choosing the basically the option of actually never upgrading and sometimes running under liable systems or very old Linux systems. So basically this ability to release every often, very often has actually made that it was difficult for these companies to switch and follow the pace of the releases. So what we've seen also and by discussing and talking in the communities is that many companies, many users of the project were actually doing LTS on their own. So I mean they would basically decide to ship with a specific version of the project and they would start maintaining their own LTS while I mean it might be good for their need. What happened is that because there were so many releases like twice a year for the last 10 years, I mean the chains of actually different companies contributing and helping each other was actually quite low because everybody was actually maintaining their own LTS on their own and it might not be the same range. So we didn't see and we did not create like a process of people that you collaborate on the LTS and we were seeing like everybody was doing their things on their own and that was a lack of efficiency for everyone. So over the years, this is something we've heard. We've heard that at every event. I mean this kind of events that we do every year, twice a year, all the Linux Foundation events. We have Dev Days and we have the mailing list and all the displaces where people can talk about the Yocto project and with our communities. And I mean we've heard a complaint and what happened is at the end of last year after the last ELCE in Europe, the Yocto project technical steering committee, the TSC has actually made a proposal to the governing board about what it would take to actually design and do the LTS and start the LTS and especially what it would cost and what it would look like. So we have had like several rounds of discussions, quite interesting and active discussions among all the membership. And the result was that we were able to announce in March, so a couple of months later that the next release, which was done in April, 2020 would become the first LTS. So we are very happy that we've been able to address something that was seen as a gap for the project. And again, I mean not everybody needs an LTS, but the users that need the LTS for this user that was a very important gap. So we've announced that and now we are going to see what, how we implement the LTS and how we plan to implement the LTS for the Octo project. So basically what we want to do initially at least, we want to have an LTS, officially maintained by the Octo project that maintains for two years. This is the initial plan, that's basically the founding that we have today. We definitely hope that things will actually, people will attract and will start, I mean collaborating more on the LTS and that will become more important for the project. So we might actually be in a position that we can extend that plan to more than two years. Basically we'd pick every two years there would be a new LTS release and we will maintain that release for two years. What we, it comes at the cost of reducing the maintenance period for the stable release. So the stable release will be the release which are in between the two LTSs basically. So what's very important about that it's actually founded by the Octo project. So we've hired, we actually sent a document and we actually asked for people to help and we've received several candidates that I wanted to actually contribute to the project and we've decided to work with Steve Sackerman who has been a developer for the Octo project since the very beginning. So it's a very well-known face in the project and in the embedded Linux space. And we are very happy to actually work with Steve today and Steve has actually become since May, the official manager for the Octo project, for the current release, which is the 3.1 release. So we'll see exactly what all Steve is playing but basically is the maintenance. So you don't necessarily expect Steve to fix all the issues and all the security issues and everything but Steve is going to be responsible for organizing the community and managing the branch and managing the testing of the branch and making sure that we get like a high quality LTS release and support and within our community. Overall, obviously, this is the Octo project artifact. So the TSC is responsible for the LTS release, the process and the TSC is also responsible for the maintenance and the quality of his work. So the components, so what, I mean, again, we haven't really talked about that but the Octo project can mean many different things for many different people. I mean, they are like a very large ecosystem of players in the open embedded space. So it's very important to define what we want to cover, what the Octo project officially covers for the LTS. So obviously we are going to cover all the components that actually make up the Octo project release, the so-called Poki release, if you want. And it's basically going to cover BitBake, open embedded core, the Meta-Yokto base port, which is basically a set of base ports for the reference platforms that we use that we test the platform. The release Meta Poki, which is the reference distribution that the project uses for the testing. And obviously the Yokto documentation as well is part of what is covered by the LTS. It's very important to understand what is not covered as well. So Meta open embedded, for example, is not covered. That's not something that the Yokto project is actually maintaining. Vendor layer, so if you use the Yokto project, I mean, very likely you use some vendor base port layers or any other layers for different application layers or application vendors, this is not going to fall under the responsibility of the Yokto project to maintain for the LTS. What we do hope is that the maintainers of these layers, at least the main ones, will also adjust and work with us and maybe, and what we are starting to see is that these maintainers want to align and actually support their own layers for an extended period of time as well to actually match what the Yokto project is doing. So again, this is all new and this is just the beginning. It's been just like two months since we started and we really hope and we really can see that there are more and more people that are interested into that. And the key thing here now is that there is one release which is actually known to be the LTS. So there is no confusion now if you are a user of the project, if you are, and if you want to build your product, I mean, you go and you pick the LTS and you know that there are going to be many different companies and many different users that will also use that. So we basically opened the door for much more collaboration compared to the past. For the testing, this is a Yokto project. As I said, this is completely part and integrated into the Yokto project. So the complete testing will be done on the resources, I mean, the Yokto project infrastructure. So builders and testers and everything will be done by the project. We will follow the exact same process and testing process as any release that we do today. And yes, for the testing, what we decided what the TSC proposal was, to only do testing on virtualized platforms, basically TUMU on all the architecture and we will not be running testing on physical machines like we do on the Bigelbond, for example. Something which is also quite important to understand this, we will only support a subset of the host distribution. One difficulty for the Yokto project is to keep up to date with all the various Linux distribution out there, the host distribution that users can use across the globe. It's very difficult to keep the system always building. So we will basically decide on a couple of distributions, maybe like the Ubuntu LTS and that's the platform that we will use or the Debian stable, for example, platforms that we'll use for the testing and for building our LTS release. There are tools inside the project like CV check that can provide insightful details and reports about CVU and security issues that we will be definitely leveraging to understand where we are with regards to CV and security issues. So again, just to summarize, it's important to understand what it is, what it's not. It's a major change for the Yokto project. It's actually the first time that we go and we are able to hire significant resource from the membership and that actually we directly fit into the project. So that's, it's been a very important discussion for the membership. And it's actually a good testimony of what the membership can do. More members means that we actually have more options and we can do much more for the project as well. So that's definitely something which is very, this is why I said at the beginning, it's a very interesting use case with when all the members come together and if they want something, I mean, we're working with the TSC, we were able to make some big impact. It's a place, it's what we have, what the project provide is all the infrastructures and the maintainer. So actually the community can come together and collaborate on the LTS. We are not going to claim that we will provide with one engineer, one maintainer, a complete secure system for everything. What we hope is that we will create enough noise around that, that people will start contributing. And if you actually look today already on the branch and what happens on the mailing list, we see today that there are much more patches being managed on the LTS than there has been in the past already. So we do hope this is actually going to be the winning factor for the project. And yeah, as I said, the project has the fund and has the resources. So this is going to be supported for the next two years. And we'll see as we reach as we get closer to the end of this two year period, we will definitely look back and try to understand what happened and what is not good so well. And we'll see if we can extend that period and how to deal with that. What it is not, because it's also very important, it's definitely not a replacement. There are actually many companies out there that actually provide a complete solution, OSV for the long term, very long term, like think about five, 10, 15, 20 years of support. And that's definitely not what we want to do. We want to help customers to get onto LTS. But if what you're after is this kind of commercial offering, that's not what the project is going to offer. We won't be able to guarantee that every CVE out there will be fixed in a timely manner. We are going to guarantee that we will do our best to provide all the tools that it might be done. But I mean, there is no guarantee that the project has some of that. And yeah, and obviously, as I said, we are going to do the LTS on a subset of the project components and with open embedded, the number of layers out there is very large and you have to get closer to each layer maintenance to see what their strategy is with regard to LTS support on the long term. So if we actually look now at the Yachter project release, so we used to have master and stable every six months, a new stable, they would overlap each other and people could decide to be on the master branch, contribute to the development of the next release or to be on a stable branch and decide when they wanted to choose. Now what we say is that the project is going to give users the choice of three different streams. Obviously, the master branch will be there and we definitely hope and want more contributors to the master branch. That's basically how the project live and all the new features come into the master branch. The stable branch will be much shorter. So they are going to be reduced to seven months instead of like the 12 to 18 months that they used to be. And then the LTS is going to be there. So as the user of the project, you will have to decide which release stream is the right for you. Obviously, master is obvious. I mean, if you want to develop and if you want to bring new features into the project and then if your project requires and you have the ability to switch quickly, like if upgraded your system is actually simple and fast, then you can actually stay on the stable release and then every six months, every seven months you basically switch and you keep your system or always quite recent in terms of the open source components. And then finally the LTS. So you can actually start developing your product on the LTS and you have some guarantees about how long it will be supported. So again, as I said, what we put in place here is a process for you to come and help and contribute to the LTS. The success of the LTS is also how this community is going to come together and contribute to this branch. Again, we don't have the resources and the funding to actually fix everything. So it's all because we are going to come together that we are going to make this LTS better. It's nothing actually very surprising. It's just basically following the typical and all the standard of the October project open embedded contribution guidelines. Just basically we use mailing these four tags. It's actually a good idea to send these patches to Steve. It's also a good idea to tag them with Dan Fail which is the code name for this release. It's actually obvious to Steve and Richard that this is actually something that is meant to go to the LTS. Obviously you should test this patch. I mean, when you send your patch on your back port that means actually that you have made this patch or you have back ported the patch and you have tested the patch. What we want is that all the patch should be sent to master. That's been the rule for stable branch all the time. That's many projects do these things. Obviously we are going to have exceptions when some newer version of a component is present in master and we need to fix it. I mean, a CVR bug fix. I mean, this is definitely an exception but most of the time, I mean, we don't expect that you send the patch directly to Dan Fail if it's actually something that is applicable or can be fixed on master first. What Steve will be doing, our LTS Mentana, it will basically monitor all the incoming patches and make test branches with one or many different patches or group of patches and it will do his own testing, a bunch of build testing and runtime testing on the QMU platforms. And when things look good, it will send the patches on the list for review so people will get a chance. What we see, what we observe sometimes that Steve is sending like 20 patches and some people decide that this is probably not something which we want on the LTS so there is actually discussions and that happens on the mailing list for that. When everything is ready, basically a pull request is sent and HR is going to merge that into the branch. I put a link here. This is the branch that contains what is going to be into the LTS soon. So if you want to help with testing with the LTS, that's basically the place to monitor. Again, all the development process just follow the standard convention. So if you are already part of the Yocto project and you are already contributing to Open Embeddy, there is nothing new. And if you want to start contributing because you like the LTS, we have many places where we have good documentation that actually explains how to get in touch with our community and how to start contributing. So don't hesitate, we definitely need all your help. And with that, I'm going to give it back to David for the last few words. Okay, thank you, Nicholas. So how can you help because we're an open source group. You can certainly contribute in your bug fixes, your CVEs and security patches, please. Test against the LTS branch with your distro and BSP in case you might find things that we don't cover in our own test matrix. We look very much like to have your knowledge brought into our open source. Please report bugs, that's how we can track how things are falling out and what we can address and fix. And please continue to test and develop on the main release branch so that we can always compare and contrast. And of course, join and support us with the Yocto project so that you can join our community and share the benefits of our people coming together as Nicholas was saying. So there are surely the bug boards, we have weekly maintenance meetings, technical meetings, everyone's welcome to join. We have it actually on our list here. We have the minutes listed on our Yocto project homepage and you can see what we've discussed, bring up your own questions, talk to the experts directly each once a week. We also have our once a week bug triage where we cover the defects and make sure we get things covered and try to sign the defects as we can. And we welcome you to join and help us bash down those defects. And again, we've the benefits of our community coming together and making our distributed repo building system Yocto project. And certainly yes. And please join us for our Yocto project, Dev Day this Thursday. We're gonna meet the people directly and actually play with the whole system. So I think with that, we're able to move on to the Q and A. Okay, so I tried to look at the questions of where we were and we're all new to these platforms. I'm very happy to see that two of the two questions were actually about how to start contributing and how to get started with the project. So I'm very happy to see these questions. I answer the questions. I don't know exactly if everybody can see the questions, but on the Yocto project website, there is a documentation page where you can see fine guides to how to get started with your first build. And then we have guides for different things whether you want to do like a baseball development or like, I mean, a recipe development or the full reference manual. So they go, I mean, obviously the first guides are simpler than the last ones, but we have a huge amount of documentation that actually something which is really excellent with the project. So this is there on the Yocto project website. I can't be on Slack at the moment, but again, if you don't find the documentation, we will ask the question, just find us on Slack and we'll guide you later. There was another question about how to get started and if there is some newbies guide, yes, and so we don't start with the difficult issues and yes, we have that too. I share this link. So we have a Yocto project newcomer wiki page where we basically explain how you can get started with sending your first batch and how do you engage with our community? So there is another question. How common are the security fixes for particular LTS? Is there a need to update security fix very regularly for an LTS? I guess I mean the answer to this might be very specific to the project you are building, but most of the time you should care about the security fix and yes, I mean it's very likely that you need to update and that's actually one of the reason why we are setting up the LTS. So Nicholas, I cannot see the question. So this is all up to you. Somebody says the page is empty. I mean, I don't know exactly what this is. Please, yeah, I mean there is a question that the page is empty. So please come on Slack. I'll be there later, David will be there and there are actually many people, I mean all the key people from the project are actually hanging out on Slack channel and will be able to help. Is there a way to do one off monetary donation to the Yocto project? Yes, there are ways and please find me somewhere and we can talk more about that if you want to do that. Yes, that's right that I mean becoming a member is kind of you engage a company for like it's more, it's not like a short term donation, it's more like a long term engagement, but there are different ways you can help the project if you want and yes, find me on Slack or anywhere and I will definitely help you with that. Okay, questions keep coming, sorry. Will there be releases or tags within the LTS branch? Yes, there will be, like we have the dot release, the famous dot release that we've been doing. I think we've released a 3.1.1, which was the first dot release on the 3.1. Yes, two weeks ago, two weeks ago. Yes, there will be. I don't know exactly how soon we will have releases, but yeah, I mean there will be a release and if you want to know the cadence, please again, come and find me some on Slack. Are there any suggestions for back porting new recipes into older distal? David, do you? I'm sorry, say again. Are there any suggestions for back porting new recipes into older distal? So like if you're fixing an existing version, you're just updating the recipes and the content, definitely yes. If you're trying to fix defects against older existing released versions of the packages, definitely yes. What we're just trying to avoid is the bumping versions. We want to make sure that stable branch of the LTS branch are stable to the versions and that all new versions of packages happen on master. They go into the next stable release or the next LTS. And again, I mean this is going to be a two year period. So we know we are going to have to make exceptions and we will deal with exceptions when they go and when they come. I mean, there are situations that maybe we will not be able to follow exactly the rules that we've set. And again, that will be discussed on our regular developer mailing list. It will be discussed with the TSC and we'll see how to proceed. But generally speaking, we are not going to upgrade large number of packages in the LTS. That's actually the promise of the LTS is that you don't change the API, the API of the system. Okay. I see question number 10. Let me take question number 10. Do you test the security fix against your entire Yachter project package for an LTS? So yes, we do test the entire, we do full QA run everything. So when we get a security fix, you'll be gathered with all the other fixes for that particular update for the LTS or stable release and we'll do full QA. So the question, the answer is yes. That was from Vindu. Okay. So now I actually found more questions. So this interface is also new for us. So how many years do you support the LTS? Two years. Initially, that's what we are funding for two years. We do really hope that more members will actually come together and join and we'll get more funding. But at this moment, we have the funding for two years. But there is good chance that most many companies will want more LTS and more contributions and we hope it will come. Is that better to use Yocto than use the high level tool suite? Beta Linux from Xilinx is a source code. Okay. So that's a really good question. That's slightly away from the LTS. There are many companies out there that actually use and make their own Linux system that also use the same tools and guidelines and the layer model from open embedded. So what we have done inside the Yocto project is we have a compatibility program where members of the project can actually claim that what they do on top of the project whether it's an application layer or whether it's a distro layer or some base port is actually compatible with the Yocto project. And be compatible means that you are a nice citizen and you basically follow all the rules and the guidelines that we do in the core of the project and you do that in your own projects. So what that means is that you can start mixing. So you can basically go from one vendor and get their distribution. And then you go to your board vendor and get their base port. And then you can take things from the Yocto project and you can actually make your new Linux system which actually actually makes, made from bits and pieces from various places. So I'm not going to say one way. I mean, one is better than the other. Hopefully if all the vendors out there provide a layer which are compatible with the guidelines that are provided by the Yocto project you can actually mix and match and then take bits and pieces from different places. So that's actually the promise of the project. There is a compatibility program. So we actually run tools, we can actually run tools on your layer, on your behalf to make sure that you behave well and don't do obvious mistakes that will make your layer something that is going to break somebody else's layer, for example. So if, again, that's something that you're interested come and talk to us later and we can definitely chat for longer. Meta Open Embedded is not covered by LTS. It's actually not, I mean, the question is that it's not covered by the Yocto project LTS funding. That's what I said. And the question is, do you still take patches for two years? I think it's a question for the Meta Open Embedded maintainers and you can find them on Slack, I'm sure. You can ask the questions there. We do hope that overall, yes, I mean, this will happen. But again, this is really a question for the Meta Open Embedded maintainers. You mentioned not changing the API in the LTS branch. Is that strict? Or do you allow additional features letting you use a backport feature from head into LTS? It is strict and we open to exceptions when there is enough consensus or when, I mean, something happens that is actually when it's actually needed. We made like an exception like in the last two weeks for some reasons. Again, if you have something like that in mind, I mean, we need more concrete details for sure for that. Again, I mean, the door is strict, but open to exceptions. I mean, when there is no better options. Someone is asking, I think again, will there be releases or tags on the LTS branch? And I think I answered that, but yes, there will be. There is already the Yocto 3.1.1 tag, which has been actually applied two weeks ago on the LTS branch. So yes, and there will be 3.1.2, hopefully soon. So I see a question. How common are the security fixes for a particular LTS? Like, is there a need to update security fixes very regularly for LTS? So we have a regular release cycle. You'll see them the .1, .2, .3, and we accumulate all the security fixes into those. So definitely if you wanna keep up with security fixes, watch for those dot releases to be announced. It'll be every couple of months. And that is where you can make sure you have the latest, greatest of the LTS branch, including in this case, the security fixes. I'll also ask, there's a question I see, is there a way to do one-off monetary donations? Yes, please, to the Yocto project. Asking, yes, small team. Yes, please contact Niko or the community, or Richard, and they can certainly set you up with the contribution. And we very much appreciate that. Okay, so. That's the next question. Will there be releases or tags within the LTS branch? And so, yes, that is the dot releases I was mentioning. As Niko said, we just came out with 3.1.1, that's our first branch on the LTS release, and we'll be following those are a few months with a .2 and a .3 throughout the lifecycle of the LTS. And that's how you can track where we are with the LTS. Okay, there is one more question. Do you feel that having an LTS will encourage people to stick to that and use old software instead of moving into a recent release? Well, I mean, we've decided that we wanted to have LTS, so we definitely want actually people to actually sit on the LTS and use the LTS. Again, I mean, we, I mean, the project cannot make a decision. That's basically a product owner decision, whether you want to run a stable LTS for, I mean, two years, five years, 10 years, for that's basically what the product requires, or if you need to be recent. So, again, that's something we cannot really decide for the product owners. There was no choice before. It was not possible to have the LTS. So, we wanted to have one more choice on the table for the users. And we'll see how it goes. I mean, definitely, I mean, if there is a need to have a very stable software maintained for a long time, maybe that's the place for the LTS. So, yeah, we have a follow-up on that. So, definitely we don't fear it. We actually encourage it, because as Nico mentioned, the previous problem is that everyone had their own LTS branch, and so everything was very divergent. So, this really allows us to be convergent on LTS, and we can all really share and cross-pollinate our resources and things on the same LTS branch. So, this is a good thing. And so, ourselves, we like to work on master and on LTS in my own company. So, that's where we focus on. And everyone has their own solution, depending on their life cycle speed, but definitely don't fear it. This is good for all. Okay, I think we are reaching the end. So, thanks everyone for this interesting virtual experience. That was the first for, I guess, both of us. And on the last slide, you will find how you can actually get into our community. We just, I mean, I mentioned mailing list a lot, but we're also there on various social media. We have videos on YouTube. We are also using Twitter and LinkedIn quite a bit, and Twitch as well, from time to time. So, thanks everyone for joining us today. If you have any questions, we'll be hanging there on the Yocto Project Slack channel, and we'll hopefully be able to answer all the remaining questions. Thank you. I'd also like to thank the ALC staff for really helping us out and our technician who's been helping us out with this presentation. Yes, this has been new for us and very enjoyable. Thank you for joining us.