Greetings, it is that time again, the mic still works, yes? Hello, hello, hello. Hello, your mic works as well, excellent, perfect. I see we've got Daniel on the line as well from Flux. Perfect, okay. This is your opportunity for a mic check, if you'd like. Can you hear me? Yes, that sounds great, awesome. Yeah, now carry about your day. We'll give everybody a few moments to be able to come on in and then, you know, rock and roll. It's just a kindness to be able to do the mic check at like the top of the meeting before everyone gets in here. For sure. The part where everyone's like, man, what's it, what mic zoom pick today, yeah. All right, we've got 25 folks in the line in two minutes past. I know we're probably going to need most of the time today. So, Dimms, your show, handing to you. Yeah, hi everyone. Today is April 19th, and this is the meeting for the CNCF TOC. You're all here, so you don't need that. Members here today will take note of the people who are here and whatnot. Today we'll be mainly talking about Flux and their application for graduation. Next slide, please. So, can we quickly identify who's here from the flux side? I know Daniel is here. So, yes, I'm here. And other flux maintainers are Philip, Max, Michael, some touchy Scott. That's all I can see right now. Let me ask you more. Sounds good. From the TOC side, I wanted to make sure we have Matt, Cornelia, Harry, any of them around? Cornelia actually gave regrets. Matt is also regrets and will give Harry a few more minutes to be able to come on in. So, yeah. Thank you. Just let me know when he joins. So, Daniel, I guess you'll be taking the lead today from the flux side.  Yeah, maybe myself and Michael. So, here is the full text of our graduation application. So we've been in incubation since, I think, more than a year now, and we've been working through basically all the checkboxes we needed to take with her governance process for, I think, one and a half years now. It's been working well for us. We have quite a few people from Weaveworks who maintain flux, but we also have from other organizations. We completed the security audit, and we fixed all the issues they found, and security also has been a big focus lately. We've also been writing quite a bit about it, and adoption has also gone up quite a bit. We've seen bigger and bigger deployments everywhere. Michael, do you want to say if she was maybe what happened on the technical side or anything you would like to highlight? So there's really one major change on the technical side, which is that flux was a version one when it went into sandbox or around that time. And then I think since incubation, we've been developing a version two, which is the same idea, but modernizes all the APIs and so on, so that they work with things like custom resource definitions and Kubernetes, which didn't exist when we created flux version one. So that's quite a big change that resulted in sort of a leap in interest, especially from vendors who are building things on top of flux. So we've seen there's kind of two aspects to flux. There is the bit you can build on top of, and then there is the end user bit, which I mean they're actually mostly the same bits, but two different types of user. And both of those have, I think, seen a sort of leap in adoption since we started flux too. Okay. Thank you. So, to start off, are there any TLC members that would like to ask some questions or I can get started too. I see Richie, you are here and you have the video on. Would you like to ask something? No, I read everything. I'm pretty happy. Okay. Thank you. We do have Harry on the line. Harry, hi. Hi, yeah, I can hear you.  Okay. Yep. Okay. So I wanted to ask you about the governance process that you mentioned. How has it been working and has there been, you know, diversification of the companies, you know, what stage you are in at this point. So basically we defined roles in the project. So we have maintainers contributors that all of this needed to be spelled out and basically all the processes are on GitHub so we have voting and let me check. So we have people from CrowdStrike, D2IQ, Microsoft, NexHealth etc. So it's a couple of other companies who are involved in the project as maintainers as well. And then the other question I had was around the bootstrapping of the project governance, the oversight committee is still there. Will it be around for longer or is it going to go away? Is there a timeline to it? Yeah, I don't think we've used it at all lately. It was mostly just, Michael, maybe you can remind me what it's there for or what it was there for. I think it's for, I don't know. Yeah, kind of. The governance influx is very deliberately consensus oriented. Actually, it is less about having a sort of, you know, ultimate authority to tie break as it is about just making sure that people are following the rules. That's why it's sort of oversight rather than, you know, the Council of Elders. In a way, it's sort of a transitional thing and it can really go away once we have figured out what should replace it, which might be something like, you know, a steering committee, that sort of thing. Yeah, that was exactly what it is. We used that exact same model in Kubernetes. There was a bootstrap committee. There was a expiry date on it. And before the expiry date, we elected a fresh set of people and they are the ones, you know, serving from that point onwards. So he has been talk about what follows it, because it seems like we need to get the, you know, solidify the governance a little bit more. That's what it feels like at this point. But it would be good to have a consensus on the plan. And at that point, we should, yeah, establish an expiry date for the oversight committee. There has been a bit of talk, but most of its private opportunities for everyone to talk are not that many. Yeah, except asynchronously on slack and so on. Possibly the cuba con one coming up or one after might be a good opportunity I know there is a kind of breakout room being planned Daniel, is that right. Sorry, I was just looking up some of the discussion about it. Can you just see the lessons again. I was wondering whether the next cuba con would be a good opportunity for more people to kind of discuss. What comes next. Yeah, absolutely. I think we have time set aside for everyone to talk. Yeah, that sounds like a really good idea and a plan. And I let other people ask questions and then we can come back to it a little bit. Katie, do you have any questions noted actually I missed the first half of the meeting unfortunately because of some of my issues but I will, I will get back by the end. So don on chat says, please come by the governance working group, they meet on a Thursday, one Thursday a month. So please join them and ask, you know, what are the various combinations that are possible and you know how to go around go about setting up something that will work for you. Okay, so the other question I had about reading through the materials was. At one point there was some discussion about the collaboration cooperation with our city folks. I know they were, there was some set of meetings and then there was an agreement to good separate ways. Has there been any follow ups on, you know, some overlap or some shading of technical stuff or components, you know, in the recent past. Short answer and which is also the long answer is no. We are kind of still in touch individually with people work on I go CD and there's a bit of cooperation there, I think. But no, no kind of official or formal follow ups. Yeah, real real quick. I'll try I'll just use up my, my voice energy for this one. There was during last con myself and one of the other flux maintainers, or one of the other people from the flux team, chatted with the Argo developers. Their booths were that far apart. And, and the idea was, hey, now that now that flux to who has been made to be componentized. Really ultimately what my understanding is I wasn't around at that time when the initial plan was made but but the idea of how flux is going to be refactored to play well with other projects as, for example, Argo has already happened and flux to just in a different way. As Michael said we have a, we have a note about what the status is of that inside the flux stocks for those who remember that earlier plan. They were interested. It's, I also spoke with Dan from code for just because they put they put a lot of energy behind Argo as well. And so they were very interested in that, especially because there are a lot of bugs in, in Argo and a lot of feature requests that are already finished in flux. And the Argo UI is something that people like the most so the thought was, why don't we just combine the two. And the only other update is that Chan went one of the other flux maintainers has created a project called a flux subsystem for Argo that that doesn't have wide adoption yet, but that's something to look out for and a lot of folks are excited about that. Thank you for that answer and hope you didn't hurt your throat too much there. How do you have a set of questions to ask the team. Yeah, I think my main question is around, what is the current adoption of the flux Portugal maybe you have mentioned this, you know, meeting so I missed that part, but what I'm curious on is, what is the end user adoption space for basically, for example, besides the club provide besides the cloud providers or vendors so what how is adoption and either side. Daniel, do you want me to jump in. Hi, I'm Tomo. I'm in the around the developer experience team here at we've works, and we work closely with our community so some are most exciting recent adopters that Daniel has just shared in the link include SAP ring and then we have other companies like soul cycle in there, like some of the more recognizable let's say like consumer names, as well as more and more people who add themselves, not only on the flux side, but on the flagger side you know now a sub project of flux and so it's been exciting to work with more and more companies who have added themselves and then you know unfortunately we work with very large financial corporations who are not allowed to add themselves. So it's pretty exciting of what they're doing with both flux and flagger and developing those areas and you know, really pushing the boundaries of of how we're developing flux for them. That's a short answer. One big to mention is the Department of Defense with working with other US agencies on platform one, and they are rolling out services for 100,000 developers which is, which is just fantastic it's huge. And I'll add to that we've been, you know, we've designed flux to obviously protect people's privacy and you know people can just download and it's. It's my job to have that very difficult monthly task of trying to capture metrics and trying to sort of connect that to how many human beings are using. So we've been starting to interview our community members to get a better sense of that and already some of the first people we've talked to would say like, well we've got our platform team of let's say like 80 to 100 people who live and breathe flux set it up for their users. And then there could be like upwards of you know 2000 developers in a company who may not even know what the word flux means. But they're going and making a change to yamal and they're benefiting from, you know, get ops. And so that's where we're starting to try to gather this information to the best of our abilities to understand, you know how many human beings are actually using flux. But that's a that's a journey that's very manual, but we're doing that because it's worth getting that information. Katie. Yes. So considering that I joined late this question might have been answered. So I'm just going to ask just to make sure that I got that covered for myself. The first question is looking at the maintainers list and the contributor list. There are maintainers but they're quite singular per organization which means if they no longer are in the organization or they no longer want to participate late that entire work is cannot be listed as a maintainer. So the question is, are there any plans to expand the maintainers and contributors from this orgs and not have just singular contributors. This is one and I'm going to put my other question. I can take a crack at that. But let me replay the question so it was the sort of one one company represented quite strongly in the maintainers and therefore succession, maybe a problem. Yeah, you're not in great. Exactly. So like, I'm looking through for your proposal here for graduation. So for example, from D2 IQ have like one maintainer from Microsoft it's one maintainer so they decide not to be there no longer. So it's pretty much one organization less which, you know, you can consider it as a commuter, like a strong commuter. Yeah. So, kind of to a two part response to that one is that there are projects which, which are driven by a single company. And that is balanced by perhaps governance by having a sort of user committee where, which, whether company is not represented. And so the government kind of has checks and balances to make sure that, you know, even though the maintainers from a single company or have a very strong representation from a single company. Actually it's driven by the community. So that's part number one. The second part is that, yes, we would love to have more sort of organizational contributors or handle maintainers. So the succession is sort of less of a risk, if you like, if we had a magic wand that's probably the first wish. But it's quite difficult being a sort of maybe midsize project to get organizations on board because it's quite an investment for people. And that probably means that organization has to dedicate a certain number of developers. And there's just not that many places, you know, willing to make that investment. And so what we get is, is more like places that don't necessarily want to make a strategic strategic investment but do recognize that their interests lie in the direction of helping with flux.  So that's our kind of route to having a more diverse set of maintainers is more likely to be in that direction. You know, until flux is quite a lot bigger, I would think. So the other one, but just to this Michael is, is there another role which is not like in a maintainer but you know a reviewer. If you have a role like that, then you could possibly have like somebody who is just getting into the community was looking at stuff and make them a reviewer first. So at least you have like a person with a role, and then you can have like contribute a ladder at that point and say, hey, you start off as a general community member, we'll add you to the get a war and then you become a reviewer and then you become an uproar maintainer like so have, if you have some kind of ladder system there, at least you will, you will set up a pipeline of folks that you could pull on next, right. Yeah, we do in fact have a contributor ladder. And there is a contributor named contributor role that is very sort of lightweight process to become a contributor and you get to be part of the organization and get some sort of triage. I think what you mean by reviewer kind of fairly light responsibilities, but you know you're part of the project. So we do have that that doesn't mean that people are sort of, you know, I think that helps a bit because it sort of makes that slope a bit more gradual. Right. But it doesn't solve the essential problem which is that it's still investment of someone's time or organizations resources to to even get on that ladder, right that someone has to ask their boss. Yeah, I think it's been time on this effectively. Yeah. So I think it probably has helped a bit. I'm sure there's lots of other stuff we could do to help that more. And there's also quite a step from being contributed to a maintain a number less with with sort of not much in between. Yeah, Katie, did you have another question. Yes. The question I had was, you're mentioning here that you have a solid roadmap and mentioning that you want to maybe work more in security and the tendency, would it be possible to share like a roadmap or more details rather than just kind of a few pointers for us to see like what's next for this project and what's going to be considered to be done well pretty much in the next year or so. It's like a follow up, you know, you can speak to it too if you Michael or Daniel if you want to, but you know we're looking for some more information when you update the PR next. I think Daniel probably knows a bit more about this than I do because he helps maintain some of those pages but the roadmap as it stands is the milestones are not so much features as they are sort of stages of maturity so you know the sort of big thing that was passed was was being having parity with flux be one in flux be to that was a while ago. The next big one is having a GA release of flux be to so it's more about sort of project maturity. We have had a push on security stuff I'm not sure whether that's represented in road maps that are published, as opposed to more sort of internal project or type stuff, which are not actually internal they're also public just not as pointed to as the road maps on the website. Daniel, is there other roadmap material. So I just shared some of the projects project boards we're using. So there's the, sorry, the roadmap document we shared in the application, and the other ones are just more detail so one view is, which I shared is basically for the next releases. The other one is just the GA focus that we that we have understood. So, yeah, go ahead. I have another question. If that's okay. So, this is more like for looking as well. Based on the on the roadmap and the next one you want to do the flux. But so far. Well, we know that flux is composed of multiple components. And we had this kind of projects previously as well. This is the kid had like three standalone projects and they actually made more sense for them to go their separate ways towards the incubation graduation. Do you envisage any of these components to take it off by itself. So all of these still part of the flux project and very kind of, I would like to use the monolith, but like, you know, like in that perspective do you perceive all of these components to be part of the same model if to make everything work, or do you envisage some of these to maybe take it by itself. There's kind of two bits aspects to that there's a sort of political aspect or social aspect in there and then there's the technical aspect so technically they're all quite strongly coupled and the they mostly sort of make sense. All together, the bits and and people can third parties can can kind of use components individually, and they do. But in terms of sort of an end user, you know, boxed product, it is all a bit at once really. Really, it tends to be mostly all the same people so there, there isn't really does not really different separate constituencies if you like. If there is an exception to both of those things, it's flagged but that actually moved in the other direction, it was a separate project, and then it came into flux as a sub project and so it seems less likely that it'll sort of break away again. It's not quite as coupled, technically speaking with the other bits. And it is sort of has its own aspects of community and so on that are not necessarily shared with the rest of flux. But broadly it's more like the motion tends to be coming together rather than splitting apart for the foreseeable future I think. Let me ask you a follow up on the flagger itself. What was the kind of thinking or process that you had in place through the governance work to make the decision of inviting flagger as a sub project of flux and how did it look like like, you know, how did it start. What were the decision points and like who ended up making the decisions and how it got to be invited. I don't remember exactly. I can take a high level stab. Unfortunately, Stefan who created flagger had to get pulled away this week and can't be here to answer that question but a very high level. We have many users of flagger who use it with flux or use it with many other tools which is equally very, very exciting. But we wanted to make sure that so originally, Stefan did design flagger with flux in mind. So, we have both a commitment to ensure that it continues to support other tools. While we also felt that it made sense to make it part of the flux project because we wanted to ensure that there was also a path that was optimized for people who use flagger and flux together because that's how it was originally designed. So that was the just very basic high level logic of thinking that it made sense to have them be a single project as opposed to, you know, having flagger be its standalone thing. So that's a very basic answer. I totally get that part. It's just the, you know, if you're talking about an open community and open design and open discussions and things like that. There has to be, you know, things written down, things done async, voting, perhaps, right. For the governance to actually work right in a repeatable fashion, where if there is another component that is coming in then would you do exactly the same set of steps or would you like, you know, change what you're doing. That's part of the governance. I know that you recently started writing down design documents for things, you know, but I don't think that was there when the flagger stuff came in. So that's why I'm poking at it, you know, where the decisions and behind the scenes or there was ample, you know, discussion in public forums where people could chime in on things. We discussed this in the in the flux meeting for for longer time. And at the time it was Stefan and Takeshi and Tetrate. It's also a flagger maintainer. They talked about this behind the scenes as well. And the idea was also to rebase flagger on top of the flux controllers. So for example, to use a notification controller for doing all the notification things that work is slowly ongoing in the process. It's a bigger chunk of work, but it just felt like it, it made sense and we had like a long this or request for comment period, and everyone was on board. I think all the flux maintainer set off on this. So that was at least at least three or four months in the in the making. Yeah, so Scott says exactly it was discussed multiple times in the community. So that's good. So basically I'm asking that because typically what happens is like when you end up, you know, taking decisions like that, you end up codifying so next time it's easier to do the same set of things right that that's how we grow the governance and like make sure that you know the best practices are captured so next time you it's easier getting through the process. Absolutely. Like one week question was also for whenever there was some experimentation going on somewhere the question was, do we really want this in flux city, are we really going to maintain this. And this is why we also created the flux city community organization where we have some projects that people started working on that still need to be tried and tested before they can, before we say okay we're going to support this. No. Harry, did you have any other questions or Katie. I have another. Yeah, please go ahead. Yeah, kind of changing the subjects as well. Another thing, which again just for visibility, and, you know, kind of seeing the progress. There have been a bunch of to do items from the incubation that you've mentioned that has been addressed, do you have a list of them that we can actually easily check. Or if you know anything on top of on top of your head that you can kind of fleece now that's going to be helpful to give me a moment and I'll find it. I know one we haven't done yet the ask was to move the flag a website. Under under the flux website to move the documentation there. And that's not quite done yet. So that's one I know of but I'll find the list for you. Thank you. Thanks Katie for that question. I know Dave just joined Dave. If you wanted to ask some questions right away. Please do or you know we'll continue the conversations that we've been having. Yeah I guess keep going I'm just jumping from other meetings I have to like pull up my notes and everything if there's stuff I have stuff I asked I'll jump in a bit later right now I'm super unprepared. Hi, did you have any other questions or anybody else on the call. I spot list to was there when we did the incubation portion. I wrote down a quick question was more to like for for for I think down is there any like relevant dependency on a project that would be at lower sustainability level than what is expected for graduation and CNCF something you would depend on that would need to be there for flux to to operate properly. And Ricardo like it CD incubators. Exactly. Now just something that could be like incubation or sandbox or something outside the CNCF. Yeah. I don't quite understand the question so can you paraphrase or are there any dependencies outside of the flux repositories that flux heavily depends upon but it is underfunded. Right, I see. So kind of risks of those being abandoned or again. So this three, I can think of off the top of my head. No, they don't necessarily have those risks that you might be able to judge for yourself. So there's to get libraries that flux depends on one's pure go implementation and one's bindings to get to those I think seem pretty stable and just sort of chug along. But, you know, you sort of never know what's going on behind the scenes. The other one I can think of as sops, which is I'm not totally sure what story is there but Mozilla sort of has changed what it funds recently. And that's a Mozilla funded project. I think there are plans or at least wishes a foot to try and find another home for it or to somehow keep it going. So those are the three that I can think things that I can think of that kind of fit that description. Other dependencies are things like helm. Yeah, which I think it does not fit that description. There's not that many, there's not that many kind of large difficult to reproduce dependencies, those are the ones I can think of. Yeah, Scott, please go ahead. Just the one update on sops is that there's been some meetings with the Mozilla team. Very recently. And I'm not sure Michael if you saw this because it was very, very recent so but but the, the, the understanding now is that Mozilla Corp will keep supporting sops. Hopefully sops is not dead. Mozilla Corp will keep supporting sops for one year and welcomes new maintainers. AJ will be the lead maintainer. I'm just reading from my notes now but I'm trying to update you will be the lead maintainer and hope to keep making releases, but the releases will be at a maintain and improve pace for now. So, you know, at the moment there will not be big feature development until the maintainers grow in number and time commitment. And there was some discussion about, you know, whether or not they may want to donate sops to sops. Or like just open that discussion. But they are not considering that at this moment. I guess the reason for asking this question is like, you know, the end users of CNCF. We, they have to have a sense that, you know, flux will be around and the things that flux depends on are going to be around so they can depend on on that. Matt, you raise your hands couple of times. Please go ahead. Yeah, sorry, I went from a phone to a monitor, so I just raised my hand once. So, I'm super thrilled to see all this, given that many organizations are basing their compliance strategies around adopting GitOps with a combination of automation. So robots do all the things. So, you know, some of these normative cases are have compliance generate documentation generated. Is there any, can you speak to the roadmap around how tooling, either observability tooling compliance tooling, auditing tooling, can in a consistent open way, get sort of the record. All of the deployments and their specifics so that there can be an open standard, sort of like open telemetry is for, you know, metrics logs and traces that can foster an ecosystem of vendors that can provide differentiated solutions to different market segments. You know, given the adoption of flux and the momentum. So are there the plans to either surface that or are there any plans to propose or work on an open standard for what just the data format is sort of like open metrics is to, you know, metrics, where it's just a wire format, so that people can integrate, but it doesn't get into implementation or workflows or things like that is just data. So is there any sort of standard like that planned, or what are the projects thoughts about that. As an eyes graduation and really, you know, increasing this momentum around get ops in general, as realized by flux as the actor. I think that's a really interesting question. And I think what to my knowledge there's not at least not out in the public discussion about exactly that thing. Flux does have a few kind of observability surfaces, if you like. One of them is that uses custom resources. So you can go look at those to see the status of things. It exports Prometheus metrics which is not a generic standard but it is fairly widely adopted. And it sends notifications to things like flag, danger, duty, whatever. None of those things, you know, the schemers and formats metrics are not standardized. I think I would expect that to go something like perhaps the open get ops group would come up with schemers and metrics and so on and then flux would implement, you know, adopt those are about Scott, can you speak to that or type to that. Yes, I was just to keep it short. I was just going to say that I pasted the timeline again. Katie for your question because I just sorry I took a moment, I just saw your question in chat. And also what you had asked earlier, Liz. So, I think the most important thing is, I tried to cover the most important thing in this, in this migration timetable. But if there's any other details with Michael if there were any details you wanted me to cover that I don't know if this or do you think it's sufficient to just send this timetable basically ensure I'm responsible for making sure that the community is aware of this, that people have an adequate time period. And the, and also the entire flux team is, is very cognizant of making sure that all of the steps needed to upgrade our seamlessness possible that's our major goal. Additionally, Kingdom Barrett has been primarily tasked with focusing on supporting flux V one users, and from his from what I don't know if kingdoms on the call. Yeah, but in any case, and speaking. Oh, right. Oh, that's right. Yeah, but in any case, Kington has said that the has been giving updates to on on the on the flux V one support requests, and a very large number of those mostly are about how to upgrade to be to and what problems are solved by by upgrading. Emily, do you want to voice please. So I didn't really have a ton of questions. So first of all, I want to give kudos to the group for making it very transparent. They're tracking completion of the recommendations from the audit it looks like you all have come pretty close to closing nearly out. And for those items that aren't closed, you have a lot of things in flight with some looks like some active discussion or pointers. However, one of the recommendations within the audit report was to reach out to the security tag. And I was curious around some of some more of the context and why that recommendation was made as well as when do you plan on engaging with the security tag. And did you have any goals or scope in mind for that engagement. The recommendation was made by the auditors. Ada logics. And that was actually something I mean we spent quite a lot of time discussing their recommendation. After that kind of made them to better understand them and I think the specific recommendation recommendation uses the security tag as an example of someone we might engage with. And the other other examples being independent security researchers and consultants. And we would like to engage with security tag I think it's something that we'd have to kind of have an ongoing like build an ongoing relationship with. We haven't been sure exactly how to engage with security tag. They are a really busy group. Yeah, we, we have a maintain a polo who I think sort of has, you know, and in there and maybe able to help us out with that. But yeah, that's something we would still like to do it. We weren't sure on what terms we would, we do that because it wasn't quite how other projects engage with them. We don't quite have the same. We didn't have an established relationship to go in with, we'd still like to do that. So the audit was sort of comprised of three parts. The first one was around fuzzing and there was a code review. And when we talked to a lot of objects in the in the very, in the very beginning, is it is anything else you would like us to to review or cover for you. And there was one proposal we started putting together around, around multi tenancy. And they reviewed this and it wasn't quite a real proposal it was, it was more in a in a draft idea and I think that's where the ask came from said like, you need a proper RFC process and talk to the security tag and since then we've implemented the RFC process. But we, as Michael said, we haven't reached out to the security tag about this yet. That's what I was sort of stumbling over towards the end there was that the recommendation was kind of attached to a particular design. And when we looked at it that didn't, that wasn't really how people engage with the security tag was not about necessarily specific signs, improving those. So we sort of went a different route on that. So I would recommend then that engaging with the security tags specifically their security pals program to assist in that multi tenancy review would be beneficial. They do have a path for that you can file an issue with the group or you can drop a line in the slack channel and see, see what they're recommending right now but the security pal is more of a direct engagement specifically for a scoped effort. Okay, good. Thank you very much. So I do have a follow up on what Emily was asking, which is. So is the security process very defined in terms of, you know, here is the incoming queue here is how you put something in which is private that the team will look at and who's responsible for doing the initial triage, and then engaging with the people to that are opening that and talking about a security vulnerability and then getting other people to work on the bug itself or a patch or work around and then the CV process at the end. Is this all documented. Do you have a set of people that are thinking about just this security process how to work it. Can we call upon Paulo because I see follows here. We can't hear you follow. We can't hear you. Paulo has been dedicated to this and is very organized and communicative so I'm really, really thankful to have follow helping with us. We can hear you. Hey dims I can jump in real quick looking over their documentation their security process is actually fairly well defined and relatively robust they have their existing process on vulnerability reporting and management they don't have a ton of details on the assignment of bug fixes and vulnerability fixes which is normal for most projects as long as they have a defined process and a way to report it they're good. They've identified the individuals as well as their fingerprints associated with it so you know that you're talking to a security person within the project and they have additional security specific documentation that is still being worked but it's fairly robust. Now, if you're happy I'm happy for sure. Let's see if follow God back in if you want to drag something. No, I don't see him here yet. Okay, opening the floor again any other questions from anyone going once twice. Thanks. Okay. So, what's this helpful. Did this the lines of questioning that you heard today. Is it helpful for you to make up your mind and like add more things to either, you know, the PR proposal itself or you know how you would do other things between now and when you graduate. The question. Is that a question for us. Yeah. Yeah, it's definitely some very good specific advice. And also, I think there's some reasonably clear sort of areas of concern. You know, for instance, dependency risk, which kind of point to maybe at least being able to write about those things and say, you know, here's the plan. There's always more stuff you can do, of course, but yeah, certainly lots of things to think about and maybe some stuff we can incorporate in the proposal. And like, I just I had just sent some text that I don't want to read out loud. To that question, to that question. After a short chat with HIDA one of the other maintainers over text. So I hope that's helpful to those asking about dependencies.  Jay, it's not, but Kubernetes depends on it. And so. Exactly. Right. Yeah, no worries. Okay, so sounds good. If we are there any other questions from the floor going once going twice. I think we can call it a wrap unless. So, thanks a lot for everybody for your time. And hope we continue the conversation. I know you're looking for a sponsor for for this and that that's the, you know, the biggest ask from you all I think. So, Amy, did you have any, any thoughts here. What we've done before in the past is like a sponsor kind of like shows up in the meeting here. I'm not really seeing that. And I feel like there's a lot of like open questions around in here. Normally, we would say, come back and reapply in six months, which for you all would be September. Does that give you a long enough time to be able to like work through some of these issues? Does that make sense? Or do you want to try to be able to look like something over the summer. I can jump in. I mean, I'd be interested to see if people have the same impression of it being pretty open ended because we feel, especially with the security audit and all the steps we went through and our, you know, we feel fairly robust application. I guess I want to understand. I mean, we would prefer not to delay another six months. You know, we've put all these pieces together and we have people, we've had people sort of share their thoughts on sponsorship. So I don't feel like there's going to be delay on confirming the actual person. We've got quite a few candidates. So, you know, unless there's some kind of strong opinion, we definitely would not want to put this out another six months. Yeah, I would say one thing that doesn't necessarily come through very strongly when people are asking questions is, you know, what the stakes are. So the sort of, you know, question about dependencies, for instance, are the stakes that, you know, if that's a problem, then no, we have to go back and rethink, or is that just, we need this information, we just need to know that something is in place you've thought about it. So I don't know how we can come by that information about, you know, what the actual stakes are with some of these questions. Is it going to stop? Is it going to be like a veto kind of situation or not. So these are all questions that we would end up asking when you start doing the due diligence doc. So, you know, where you would end up identifying, okay, these are the things that are risks, but we are not currently working on a on some of these things, but other things we feel are the team feels that it is something that they need to deal with quickly so we are going to like pull in a few people to work on something. At this point, I think we probably have three people, three liaisons to SIGAP delivery, Matt and Cornelia and Harry, I think I would give them first whack at being a sponsor. Harry, did you have any thoughts here today or do you want to take some time to think about all the discussion here? I think I will try to think the whole information is for the other chairs to reach some conclusions. Okay, so you need some time to think about it. Got it.  Just on this on this one topic. I think one thing that was fairly unclear was the triage process. I know that folks are busy as well. That's, that's another thing. But it was not clear to me. I had just informally asked Matt Farina, for example, because he had just joined the DOC, and I guess I was not able to make today, but what he had transmitted back was that, you know, hey, we should probably stop asking you folks, you know, and you know, whatever is best, of course, but that he had mentioned that there that that there was identified the gap in the in the new triage process, and at least in documenting for folks outside of DOC, you know, like what what we can expect and what we should do to help that.  Is there anything around, you know, real fast as a slight interject a slight aside, I don't know if there are any open there. I'm not sure if there are still any open questions. I believe the only ones that felt somewhat open to me until we answered them in text was the dependencies one, and that's been fairly well answered the, you know, which, which, maintainers are how broadly our organizations represented. And I don't know, I think Daniel had had mentioned this twice, but just as a just to make sure. There are now maintainers from seven, seven, seven organizations, including one independent person so that's was one of the biggest tasks during incubation. And so I think my last question around that with those caveats is for sorry, with that quick interjection is, is, is there anything else. Yeah, anything else that we we either should should expect differently or maybe could do to help with that with that triage process or you know kind of where are we with that. Yeah, so you started off with the PR with the set of questions that we asked, and then you came well prepared to this meeting and you answered all the questions that we raised. So now it is up to us to find somebody to work with you or come back to you with a clear set of asks if we want to change the date to come back. So that that is so you need you should be hearing from us, hopefully quickly. Got it. Okay. And also just to be very transparent about this. There's, there's, of course, we want to do this and what Tom said is, you know, yes, we don't want to to postpone another six months, especially because I don't know that there's anything to do with within those six months except just keep going as a project. I think the main thing the main reason I'm asking is not to put pressure on anyone but just because I know that coupon is coming up. And we just, I would, we would love us at least a project to simply be prepared to to do the right things. If that were if that were the case so we're we're right now still doing that kind of preparation work just in case. But that's it. Thank you very much. Yeah, we hear you loud and clear. So personally, if you ask me to give you something to work on right away right now would be that, you know, bootstrap committee turning into steering. I would want that written down and like an expiry date put on and a plan published for everybody to be, you know, correct what is coming down the line, so to say right, because that was kind of fishy washy a little bit and also, you know, we were talking about the process for the flagger coming in and, you know, there was. It wasn't very clear that there was a solid process that was written down that was followed during that decision making. To the honest point of view, I would look at those two today. Justin is not here, usually Justin and Emily back theme on the security side of things. So, you know, we probably have to give them a chance to ask some questions on the on the PR itself. Right. Is that fair. Yes, that makes that makes sense. We'll start on that part right away. Thank you. Thank you everyone. Thank you. Thanks for time everyone. Good to see all of you.


Hello, and welcome to this presentation of the STM32MP1 series, External Memories Overview. This presentation quickly summarizes some key points for the selection of external memories and the related constraints for an application using STM32MP1 series devices. Let's start to see which kind of flash memories can be used with the STM32MP1 series. Flash memories are used to store code and or data. Due to high processing performance needed, accessing code and or data became a bottleneck, and an intermediate workspace like an external DDR is always required. In an operating system environment, the flash memory is managed as a file system, so execute in place or XIP is not possible, and the flash memory always needs a specific driver tailored to each particular device. In most systems, there is more than one flash to cope with the strength or weakness of each type of flash technology, or to separate storage to increase performance, security, or user flexibility. This table summarizes most of the differences between the various flash technologies, which can be used in an STM32MP1 microprocessor system. Serial NOR flash technology has a very good PCB area, due to low pin count of serial devices and very good reliability. The cost of high density and the right performances are the bottleneck to use NOR flash memories for large storage. Serial NAND flash technology has a very good PCB area and better cost and right performances than Serial NOR flash technology. Reliability is often seen as lower than for Serial NOR flash technology, but error correction is embedded in the hardware and transparent to the file system. Raw NAND technology has a parallel interface, which is not good for PCB areas, but offers a good trade-off between cost and performance. Most raw NAND memories do not have an embedded error correction, and so need additional hardware and file system management for bad block management and wear leveling. EMMC devices are widely used in the mobile phone market, and so offer very good price and performance. EMMC memories embed error correction, as well as fully automatic bad block management and wear leveling. Removable devices such as SD card or USB stick are providing very good cost at large density, but at the expense of lower flexibility and reliability due to user access and mechanical constraints. STM32 MP1 series can interface Serial NOR and Serial NAND memory interfaces through the Quad SPI interface, which can support up to two 4-bit devices. STM32 MP15 series can only boot from the first Quad SPI device. Raw NAND memories can be connected to the flexible memory controller or FMC. The possible configurations are either one 8-bit or 16-bit device or two 8-bit devices sharing the same data bus. Only SLC device requiring up to 8-bits ECC are supported. STM32 MP1 series can boot from Raw NAND memory devices. EMMC memories can be connected to any of the SDMMC interfaces. SDMMC3 has only four data bits. EMMC devices support one 4 or 8 out-bit data width. STM32 MP15 series can boot from EMMC memory connected to the SDMMC2 interface. SD card can be connected to any of the SDMMC interfaces. STM32 MP15 series provides optional control for external level shifter, mandatory for the support of UHSI mode, which requires 3 volts, then 1.8 volts signaling. The STM32 MP1 series can boot from an SD card connected to the SDMMC1 interface. This slide shows the usual flash density available by technology. Note that a flash memory with a size less than 1 gigabit, 128 megabytes, cannot be used alone. As such, size does not allow the storage of the operating system, but can store data anyway when used in conjunction with another larger flash holding the operating system itself. Let's continue with DRAM memories supported by the STM32 MP1 series. Here are some fundamentals about the DRAM technology. Despite their inherent complexity and constraints, dynamic RAMs are used in many devices, as it is the only memory available with a very large density at an affordable price. DDR3 technology has been superseded by DDR3 L technology, which offers the same performance but consumes less power. LP DDR2 technology offers smaller packages and less signals on PCB than the DDR3 DD3L1, a better power consumption, but usually has a higher price and needs two different supply voltages. The STM32 MP1 series support DDR3 or DDR3L memory devices in either 16-bit or 32-bit interface configuration on some packages only. As neither DDR3 nor DDR3L memory devices exist with a 32-bit interface, this configuration requires two devices, which are using a great deal of PCB space. Package ball pitch is 0.8 mm, which is adapted to industrial robustness. LP DDR2 or LP DDR3 memory devices mostly exist in 32-bit versions and offer lower signal count than DDR3 DDR3L1s. The package is smaller, but the pitch can be 0.67 mm, 0.5 mm or below, requiring additional PCB cost. The STM32 MP1 series supports between 1 gigabit, 128 megabytes, and 8 gigabits, 1 gigabyte of DRAM memory. When designing a DDR system, DDR constraints must absolutely be taken into account. Refer to AN5031 and AN5122 for details. STM32 CubeMX provides a tool that helps tuning the DDR parameters and checking the DDR signal integrity directly on the final target. More details are provided in the ecosystem training part. All related DDR specifications are standardized through JEDEC. The key points to remember from this presentation are the STM32 MP1 series always needs an external flash memory device. External DRAM, such as DDR3 DDR3L or LP DDR2 LP DDR3 devices, require a careful PCB design and signal integrity analysis. And STM32 CubeMX helps to configure and validate the DDR memory on the final target. The recommended flash or STRAM size depends on the operating system configuration. In addition to product data sheet and reference manual, these two application notes are recommended before any design phase using the STM32 MP1 microprocessor.