LF Decentralized Trust TAC Meeting - 2026/09/10

Hello everyone. Uh good day. Welcome to Linux Foundation decentralized trust technical advisory council meeting on 10th September 2026. Before we get started, couple of reminders. The first one is on antitrust policy. Um we do acknowledge that we do have participants from across several organizations and some of those could be our competitors on this call and we request um all participants to abide by antitrust laws for for the in participate in the community. The second one is the um I mean given the diversity that we have within the community, we do have participants from several geographies, from several backgrounds and organizations. We request everyone to be respectful of each other. And if you have any comments or any topics that you would like to bring up, uh please feel free to raise your hand and u take a chance in uh speaking in this meeting. Thank you. So moving on to the announcement section. The first announcements we have is the developer newsletter. U quick reminder the developer newsletter um instead of sending a wiki note, you would also I mean you would be required to raise an issue. That's the only difference. But otherwise, this is a great community tool and forum for you to send across any updates um that you have within the project or maybe requesting for comments or more participation or requesting for people to get involved with the project and um if you haven't already used it in the past, please do leverage it. This is a great forum for community engagement. The second nomine I mean second uh announcement we have for the day is the nomination period for the upcoming um TAC elections will open soon and you may reference the timelines timelines is that uh the nominations will be happening in the month of October and potentially a new tag will be elected by um early December If you have community members who can be um great part if uh with their participation within the tag or if you want to self-nominate, this is a great time for you to uh um go and submit your nominations and feel free to reach out to uh staff or any of us on the tag if you have any questions on that. And the next announcement we have is the um Oops. Um am I audible? Um I saw couple of messages on Zoom chat. I see thumbs up from Kevin. >> Yeah, we we can hear you fine. >> Perfect. The next announcements we have is um a work working group proposal and um if you have any questions on the working group itself or the um agenda or the theme feel free to reach out to Henrik but we do have a kickoff call and I believe like this was also discussed in elaborative way in our last week's meeting and this is scheduled on October 6th. Please do spread across your community members and we look forward to a great participation in the working group kickoff call and >> hey >> hey Arun sorry I'm I'm on the mobile but maybe you can hear me and maybe I can say some words about it. So this this meetup for sure is not something like like a presentation or or something. This is really like the kickoff of creating a working group which should be like discussions with everybody and so on and so on. So um if you are interested in that don't expect a Raj presentation but we expect to discuss what we can do regarding AI on the one hand within LFDT when it comes to to development and AI guidelines and so on and on the other hand how the technology we in RFDT create and specifications that we create can interact with AI or used in AI. That should be the topic of it. >> Thank you. >> Thanks, Henrik. Um, I'll take a moment of pause and if you have any other announcements, please let us know. I don't hear any. Moving on to the next section, we do we did have a couple of annual reviews uh pending for a couple of projects. One is smooth, the other one is Minoa. And on the smooth uh we do we did have specific comments uh to the maintenance um that the pack were looking forward to uh get an answer for. We believe we do have wait okay wait here. Hey. >> Yeah, I know. Yeah, >> maybe I'll I'll let you speak uh for the pending tasks and um t members, please feel free to ask any questions you have. >> I so I know you want you want me to kind of give a kind of overview and then discuss what we have been doing and then uh take some questions. Is that is that is that the procedure? >> We we could do that. um or in this case specifically I remember there were a few questions raised by tag and um mostly the questions were um hey there is this governance structure put up by uh tag and it expects projects to follow certain directory structure and that's not seen and um like for instance I believe even the license file was not in included let me recall I'm trying to look up for. Mhm. >> Yeah, I think those have been changed. Um the I have responded to majority of the questions. Uh um trying to look up for the open questions. Um these were from Marcus There it is. >> Would you like to drive or do you want to give me direction where you want me to share screen? >> Sean, I'm trying to look up the comments from Marcus. I remember that those comments were posted in one of the tag or tag only channels on discord. Searching through that as we speak and you said Marcus is not available for us today, right? >> Marcus had a conflict and cannot make it today. Hendrick does have his hand raised though while while you're looking. >> Hey. Yeah. Hey. >> Hey. Thank you. Um so yeah actually um I think that that Marcus is is today not here is is quite sad but he has a conflict. So we cannot change it. But from from my point of two uh view we had like two topics we we would like to discuss where one topic is the concrete questions that that we had in in the document and and getting answers on it. But the second and maybe even more more important um question um Van is how um we as as a tech can include the the smooth project and and the smooth community in a better way. Um and um on on the other hand, how we can um connect with you if we have any questions in in um reports or anything like that because um we we now in in the situation that the report is open for some months. Um and this is for both sides, for you and and for us like an um uh not good situation. And um the the problem is I think what we do not have is good communication channels. How we can um ping you and ask questions to you and on the other hand how you can bring information to the tech or in best even be um part of the tech meetings and so on. So next to the individual questions within this one um review I think we need to discuss how we can make it in future reviews better. Yeah, thank you HR. This this is great. I think you you you as you talk about two two topics, right? First one is the procedure one. Those are easy to solve. These are specific question adding me change directory structure and the second one I think is more critical as you mentioned um and and and you said that the the repo has not been updated. In fact, it has been updated uh a lot for both uh uh scenario and and bridge bridge was not updated and there's reason for that and I want to discuss with tag here. Um we uh well the code what there have been some question let let me clarify on something which I described in in my response first question one of question was that well in other project they check in there's a like they check in like every time there's a commit they pull request a small poll request they check in uh uh kind of with a small change and when we check in it's a it's like a 20 files or even a 100 file changes. Why is that? Okay. And the answer that question maybe some some of you did not look into that detail. The reason we checked hundreds of files was because it's a migration which we described in the project. Um we said that we want to migrate our code to um to smooth project and and that's why there are hundreds of code merged together. Okay. Not rather than like one individual change small change like that. And then there are questions on like reaching out to communities and and David help us a lot by organizing meetups. We have two meetup. We have two blogs already last year. This is in the annual report and then the and these there are good participants on that and the good feedback on that. And then there was a question where are these uh meetup and the blog documented? I think it's all documented in the in in the report somewhere. Uh so I answer those question already. But there's a bigger question why this time we update scenario but not the bridge. There's a reason for that. A bridge is very complex. It has it has the smart contract on the source chain, smart contract target chain and then there's offchain multi-sec MPC. Any vulnerability in these places will cause problems security problems. And if you you have a system that that vest like billions of dollars, okay, or millions of dollars, it's very easy to find the one lines of defect and then and then and then attack that defect and then and then take the money and run away. And we have seen cases where you have all the engineer did the code and then you have the two official expert uh all the security order review pass. But with the AI the latest AI scanning uh the latest model they can find it the defect and then if hacker get these uh finding and then they can they can easily attack those things and we we like we have many many repos and we in fact we have 200 repos already privately and we are migrating these to the to the public and we find a case where when we use the it is AI security audit code or security review u module to review our code issues are found and this list is to everything right and that's why we are very cautious to kind of migrate those kind of code to smooth which is public everybody can see it everybody can can scan it and then we have huge concern on on the security because if they find the defect they can attack us again okay so this and this this and I and I when I talk to David I saying that maybe those kind of high power security scan code should not be accessible to to hackers and I we found that like like like yes it's just simply yesterday we were using um the latest uh open ch basic codeex uh uh um atra module and and and we scan we we we select to scan and we find more issues and we don't want to publish those those those things and then then the ashure is so powerful they use the daybreak to to limit the people who can access the the the this this powerful module and that's one thing I want to talk to tech as well is that today we're all open everything's open the this discussion open even the meeting is open and it's very very easy to attack the critical component of our code and that's why I think in the future I just want to talk about bring this up saying that should we how do we tackle these kind of things? Should we leave everything open the hackers can can can access to it things like that. And then and then communication of course these are communication part of communication I want to bring up to to you as well. I just do not find a good solution for that yet. I just I'm reluctant to open everything up right now. U yeah it's it's yeah >> thank thank you for bringing that to to the tech. I think that is what I meant right. So having those informations and and discussions at at the tech I believe that would be the best possible solution and and outcome here. But I see others have hands up so I will be silent >> status. >> Yes. uh the point of the vulnerabilities is very interesting but from my view I would like to make a distinction between the code base and the system somebody could attack because you cannot attack uh the code base when the code base is in the repository the best thing you could do is to identify the vulnerability And if uh you are not a bad actor reporting, if this codebase goes uh into the production uh is deployed, we should expect that somebody has an interest to do so. And since they take advantage and take the value of something that is open source, I guess and I expect that at least part of their responsibility is to go through some tests before they deploy and uh after that if they find anything it's uh ethical or it's good for us to report it back. GitHub has uh plenty of ways to encourage vulnerability reports. So from this point of view, I would like to make a distinction. What are the risks for those who develop the code and open source the code and what are the responsibilities for those who use open source code and they deploy it in production. Another dimension is that and I saw that happening that when you open source your code actually you welcome you you encourage security researchers to review your code and submit their reports and instead of having just the developers trying to secure the code you have plenty of people with very very vertical expertise in the field scrutinizing your code and submitting their reports. And why we expect this to happen because even for these researchers if they security researchers if they follow the formal and the common path to do so at the end of the day they get uh credits and they put these credits into their uh CVS. So open sourcing our code base from my personal view is something that secures the code in the long run. However, we should be we should do also our uh homework. I I I'm new in this call. It's my first call. So I don't know how we have set up the repositories. But if in GitHub we uh had all the vulnerability disclosure policies in place and their mechanism in place we are well prepared to improve the security of our code base. So thank you. Can I ask a little bit to to that? I saw some of the but I we discuss actually on these also because this is this is so critical. I think in the past yes it's it was assumed to be that way when you open source something it's going to be the responsibility of for whole community to to look at the code to look at the security side of it uh and then and then and then and report the security issues and then they fix it but today with the AI that security kind of a scanning becomes so so easy low barrier thing and there are certain thing that need to changed. And that's why when you look at Daybreak, Daybreak, they only allow people who pass the Daybreak V verification to to use their tool because they don't want everybody to use the tool to scan all the code and then and then take advantage of that. And you when you want to do daybreak verification, you actually need to use the government uh issue ID to pass that. and also it block certain countries to asset they break. So there's already okay kind of awareness of of these kind of AI kind of vulnerab possible danger to to the to the open source code already to scan the code and I think here's the the procedurally if we have a put we if we normally when we do some produce something deploy something to a production we we think there's no problem right and in the process when you deploy to a production you put that code into uh the open source or you put it on open source first and then you put it in the production. But today it's it's more complex than than that. When you use the AI to scan the code when you find the issue, you don't want to publish it. You want to fix the production system first then you publish it. So that's a deviation already. You don't we normally don't disclose that. And that's why I was I was talking in the in even yesterday meeting. Should we okay if I just scan the code of a repo and I say I find two critical issues and and two high level issues. Should I publish this scanning directly to the repo or should I talk to the maintainers first? Make sure that they are not using this code in production and make sure if they are make sure that they fix them first then publish it. And already there's a deviation there and we need to think about these special cases because today the the the the barrier is so low. It's just everybody can scan the code and find the issue and take advantage of it. I should agree with everything you commented uh with with just one additional remark. If we have findings uh and these findings are about an open-source project especially if let's say posted on GitHub we can report we can capture that in a place that it's not public despite that the repository is public this report will stay private until it is resolved and uh GitHub provides this function functionality. >> Yeah. Yeah. And and that's I I think that would be great. And in fact, we have two cases already. These are practical cases. We have one case somebody found a defect and took advantage of it and those are hackers. We have another case who label himself as a researcher and he told us that he found this issue and then then he said he's not going to publish it. He want us to to look at the the system and then patch it and then and then we did. we patch it and then give we give the reward to that person. Uh so there there are two kind of people over there. If we build a system that we can limit this kind of exposure of the issues because finding issue is so easy right now. Every time when you have a new new model coming up you scan the code you found new issue and it's so critical or high. It's it's it's so common right now. And we bet when you have more new model coming up you're going to find more issues. And and the challenge with blockchain was that if there's an issue and if the hacker take advantage of it, they run away. There's no way to track the identity of them. So it's not like a centralized system. You have government control everything. You you have the it's trackable. But this is not sometimes not trackable. So there's incentive for for hacking in fact. Um so I think if we build but today as yes repo has that capability has a private but I think as open source we do not have that we we we when we submit a PR it's open to everybody uh when we find issue we post there it's it's open to everybody already >> oh if you want to to answer directly on that uh stra feel No. Uh I but we need to check. I think that if in GitHub we report the vulnerability as GitHub expects for public repositories, it keeps the report private and also it gives you the option to keep pull requests that fix that uh also protected. But uh uh we need to check that. I can check it and uh confirm that this is the case at least to be sure that we have a process that helps us solve vulnerabilities without disclose them. I think that it works but I need to confirm it. And actually what what I wanted to say is from from my point of view the topic that we now dis discuss more in deep is is one of the benefits we have here with the tech and and with RFDT because and actually that is that is fact I don't know if if Ry and Jessica are currently here in the meeting they can agree it we had exactly questions about those topics in in hyro this week and and discuss them with with um Jessica and Ry. That's what I can say. Yeah, it's exactly like uh Stavo said, um GitHub has those mechanisms and GitHub allows you to create issues, security issues that are not seen by anything but the creator of the issue and the owners of of the repository or the security maintainers of that repository. And um actually that is that is a huge benefit and and I learned about it by um people here in the call from the Enox Foundation or or LFDT and and this is where I would like maybe to if if okay for Stavos and um VI bring bring this uh discussion back to because um I assume we can talk a lot about security issues and and about um how to solve them and and what is the best workflow to do so and and I would agree the tech is the right place to do so. Um but but we started with um the smooth report we had which all of us brought us into a situation of bad communication and and I I I think it would make sense to to come back to that and maybe discuss on the one hand the points we had to open. So Arun wrote he has the um message found found the message and have it open and on the other hand how in in future we can make that better and and and seeing like you here in this meeting discussing about those things that are happen in smooth uh from my point of view exactly how we can make it better. So we said to to to interrupt here but but I think that is that is the way we we should go to bring exactly those points to the tech and discuss it here instead of just bringing in reviews every half year. >> Hri yeah can can let me respond a little bit but thank you is a very insightful comment. uh the uh uh yes GitHub has a lot of capabilities including private repo and and sometimes it's the policy for example if you log a a private issue or something only some certain people can see it or you can even build a build a private repo I suppose uh but I when I look at the rule of this uh LFDT project or lab or expensive project I think it's supposed to be all open if you look at the governance document I remember Every meeting should be can be should be reported open to everyone and all the documents should be open and that's why even even you lock the issue when you discuss in the meeting right you need to discuss this in the meeting and we are not supposed to have private meetings right you are supposed to have public meetings and then this the discussion is kind of limited even if we have a tool over there well GitHub is very powerful you you you have private things no problem but I think it's the communication that that can you do that as a governance process? >> Yes. Yes. Yes, you can. And what I would um recommend is that you um yeah, we should not discuss actual vulnerabilities in public court. Point one totally with with Strauss here. But what you can do as a project as smooth for example, you can define security managers. You can define GitHub accounts or GitHub group to become security managers. And once you have that done, you can allow to create security issues. And if I at smooth create a security issue, that issue is only visible by me and by the security managers. And this can even end in creating a private fork within the org of the project where only I and the security managers have access to to work on a fix for it on it before it goes live. And what I would say yes everything should happen in the open without that. And if you have security managers that those security managers have meetings that are not happen in the open, I would say that is totally fine and is not against open source. It's against ri risks. As long as the security managers are um erected by by open governance, I believe it's totally fine to have them do things in private within those workflows like somebody creates a high security issue which is private only seeable by them. that is something we we must do to make the use of the software we provide safe. >> Okay. Well, thank you Hrick. I think the what is very useful uh the but remember very clearly when we were talking about forming this project there was a governance document that was signed by legal of LFDT and there was by lawyers and then they there was a sentence saying that every documentation should be open source right at the beginning because I I opposed to that I was saying that well some document are not kind of a mature yet that's why we want to work privately as a as a private document and And when later on we find it's good enough then we we put it as a public that was rejected that was rejected in the governance document saying that you have to make that documentation open source right at the beginning to be open to everybody so so now I want to go back to maybe maybe that has maybe that has been changed but that's that's in my mind all the time saying that everything has to be open right at the beginning and that's why I kind of raised this question but if you said that those be private at the beginning and then they don't mature to get become public. I I want to go back to check that one because I remember clearly in the government. Yeah, >> I I I said my private opinion and I'm not from AF, right? So just just to make that sure. I said how how I see it and I'm just yeah seeing thanks um heart for for answering you because I just wanted to see say we have heart here. Um but he's just writing something. >> I'm happy to jump in if you want me to talk if you want to call up. >> Yes, absolutely. I I think you're the right person at at this point to um say something. Thank you. >> Um for the AI bugs, the Linux kernel team at least has taken the policy that uh they should immediately be public. There are two main reasons for this. The first reason is that as soon as the tools have found the bugs, then they're going to share them with everyone. The kernel code at least there are many people scanning with the AI tools. So as soon as say you know Claude finds a bug then everyone running Claude on the codebase is going to get that bug back and so it may as well effectively be public. Uh the other reason behind this is that people were massively reporting the same bugs to the security list. So if like a hundred people all report the same bug, it becomes unmanageable. And again, it only uh supports the point that that bug is public anyway because so many people have found it using the same tools and are all reporting it. Um you know this might be different if you have, you know, secret access to some advanced models, right? you know, if you if you were an OpenAI employee and you found a bug with a super advanced non-public model, then then maybe this wouldn't apply. Um, but this is almost certainly the case for public models. Um, you know, this is again just the colonel's decision. Um, they have a lot of eyes on the project, uh, which has has led them to to make this decision. Um, but I just thought I'd bring that up as a a point of discussion. >> Well, thank you, Hart. I think with the Astro one Astro AS by open open AI I think the if you look at the date break policy I think they they ask you to verify it and I think there's a land disclosure uh clause over there saying that if you this is open actual is a open model but it just need breaker verification means only the security researcher can access it and and what with Then there's a foundation policy here if they find a security issue uh with uh daybreak uh capability and then the actual should they publish it because if they publish it seems to be violating the rule of actual uh policy >> and Ricky >> so this is all fascinating conversation um Arun can we bring it back the report could we just please like try and assess what we're missing from Wjin on the report and how we move forwards. I think interesting the world of security and vulnerability disclosure and the process for that but can we just bring the conversation back please because we have a lot on the agenda today. >> Makes sense. Um I agree. So wait it would be nice if you can send a write up to the tag um on this topic. We'll definitely build up for discussion in one of our upcoming sessions. So u specifically for smooth the concerns that were raised is mostly on the compliance on in terms of here is what best practices set up by the LFDT community and um smooth is lacking behind on that and these were some of the identified gaps the ones that I'm sharing on the screen and um we can um I mean if you can have somebody take a look at this and um have a highle estimation on like hey we will be able to address P 0 by so and so date or like P1's by so and so dates things like that I'm I'm sure like T will be receptive of um T would like to want like hear from the project team okay so you want me to you shared the note here right on on the screen. You share the screen here, right? >> Yes. >> Do you see my screen? >> Yeah, I see your screen. Yeah. But it's it's it's very Yeah, it's a lot of readings over there. Uh so do what what be the uh the the agenda for today's call. Actually I have uh yeah we are you going to vote today or you or you want us to respond to look at this note and have a chance to respond. >> Um we we could definitely so in the past um TAC had some challenges in reaching out to the project team. So let's do it this way right. So I I um we will probably go ahead and ask uh Marcus or maybe I'll go ahead and share this to the project team one more time and um um if you have some timelines by when you can respond back to some of these questions I'm sure TAC will be receptive of that and um today we can go ahead and open up the project report for OT and um it's just that needs commit ment from project team that these will be addressed at some point with with the fixed timeline. >> Okay. Yeah. Yeah. We yesterday we had a meeting our next meeting will be two weeks later. Uh so what I I think I definitely see we have some challenges there already. Okay. Which is so there are several thing one is procedure. We think we can fix those uh easily. uh there's those not no problem and we have tons of code also there's no problem with with the code itself I think the the challenge for us okay uh if you look assess the health of this project is the adoption it's is how many people are going to use the this framework and how many people are going to bring this to production that's one concern we have been debating because recently have been hacks on bridges a lot of hacks on bridges and and and and we we have concerns on that. So it's that who is going to adopt it, who is going to kind of take the challenge of potential security thing and that's why discuss in the AI with the AI thing as well. So I think you you have it here already community and tech uh standing this like broader borden maintainer or contributor diversity. We try very hard to get more people to be involved in including deo um but apparently we could not get those participants and if there are people who are interested we we are very open-minded we welcome these people but if tech can help with that people who are really interested who want to contribute to this project we welcome them to be to be maintainers so so I think we those are more difficult the adoption security and then the diversity of the particip and those may need some time and we are also evaluating the health of this project as well. Is it do do we have a chance? That's something we're evaluating as well. We don't want to work on a project that's just stay on the PC level. We want it to be to be used in production and that that that has some challenges as we evaluate evaluating uh ourself. So I think in terms of response at least two weeks okay but if you can give us more time that that'd be great. Thank you major. Um so this is question two pack now based on what responded if you feel comfortable that um the smooth team can get additional time to respond to some of these questions and if you're okay with the project report itself I would need a motion from the pro uh from the tag and a So, wjen um on the project health, do you have any like bullet points that you can like list on actions you're planning on taking? Because you're asking for more time, but with in that time, what what are the actions you're taking? Right? is we have a standard for incubation projects right and and you've stated that there are some concerns on project health and I think it's an opportunity and this report is not just about voting a report it's about understand the health of the project and if the project needs to be moved to a different category within the life cycle of projects and that's what we're debating today okay um so given all of this what are the steps the concrete steps you're going to tackle um to make to make the project health better and and in the ways that you've described. >> Yeah. Uh I think this uh well this report is for 2025 in terms of project health for 2025 it it it went well. It it there so many code checked in and no issue what was reported at that time even the when I I read this status report uh with the link provided security was was green at that time. uh but today if I look at the security problem we're not going anymore. uh so so uh I think if we are talking about the health of 2025 it is good I have no doubt about that that that 2025 was a good year for for small project I think my concern is 2026 uh 2026 what we we have three phases the first phase was that uh uh migration of our code to smooth as open source that was done so that that's fine and then we have second phase is to uh combine with other interobidity project and then harmonia was combined with us and the code was migrated to smooth as well. So that went went fine and then the surface was the the adoption uh of the the product somebody need to use it and then the contribution from the community that one was my concern has been my concern now we have another concern which is a security so my if I assess it because we are at the we are at the stage of deciding whether we want to spend the money and effort to maintain this or not we are debating on that ourself it's not right we We yeah >> so that's >> that statement right there wjen right that statement that you're putting here on in front of the TAC with everyone is a very very important statement to highlight inside the report right that >> the future of the project today >> is under in like investigation right you're not sure about the future of the project today irrespective if this report was for 2025 we are in September of 2026 right so if we're going to make a decision as the TAC We need all our facts on the table and we need to know what is the investment in the project and that will will will make us understand where does the project fit in terms of the project life cycle of the LFTD. >> Right. >> Yeah. Yeah. >> We cannot just take a vote on historical past information. That's why I'm asking you about what are what does the future look like? Because when we vote we don't just vote on oh this happened last year so we're green and we just tick along. We vote on how do we see this project going forwards as well. Yeah. Yeah. I I fully understand that. So we are in the uh critical point where actually we as a as the I'm coming to presenting uh our project we are at the critical point of making that decision oursel as well. Uh so I think that timeline for us we cannot make the decision right now as of today because we still have some pending items that that that we need to resolve. Okay. that will be about like two months two months time for us to to make the assessment. uh um so what what I can describe is the the the obstacles I we have so far I described to you community participation potential use case adoption and then the security concern uh so will this thing be successful overall in the future that's something we are debating right now and I think uh uh internally we probably need two two more months to to have these things uh decided some not can you hear me? All right. I'm not sure. >> Yes. >> Okay. So, uh it's we're we're at this juncture now where you know is there a probationary period um or something we they right now accepting this report as is isn't really um a good precedent um to say the least. Uh so I'm just wondering in the government um of this um where what what we can do here to give you that time because I think um I've been listening quietly in the background and I'm I'm not an expert on Smoot or or even AI um tools using you know to debug stuff but it's it's sort of um it's it's there's a lot of questions here folded into this whole conversation and if Um, Smoot is having difficulty establishing an open development process um and you know and a disclosure model that um that um that they're willing to live with that allows um outside participation. Um, the kind of there's a more fundable fundamental question here that I think we're trying to tease out is whether smooth is viable as an LFDT hosted open-source project um going forward if the the risk is too high for um for um the the company that's doing most of the work on it to do this and and and I think Wayen is acknowledging that um and giving them two months to do that but that doesn't so for us we have to decide well we can approve this report or accept this report maybe as opposed to approve it um and and move forward from this and then in two months come back to them evaluating the health of the project and whether it has um a chance to progress beyond PC status um and and I don't even know what the process is for withdrawing a project or archiving a project really um of this nature if they decide not to continue with the PC. Um so I I think that's what we're trying to tease out here. Uh and um if you if it takes two more months, do we just postpone? I I'm asking Arun and and the other governance people um or their opinions too. But what is the effect of accepting this report um rather than approving it maybe? Um so I mean if I hear correctly I mean the T is still not comfortable and accepting the project to be in incubation phase. That's what I hear. >> Yeah. Oh, definitely that um from for myself, but um you know, it it sounds like they're going through an an internal process of maybe just stopping work in the public um under LFDT if I'm hearing reading between the lines here if they can't figure out good solutions that um for this for their purposes. So um I don't think we've been at that juncture before. Um or at least I haven't on attack. >> Yeah, I think there Diane. Well, thank you. Let me can I respond to that one? So there's uh well when I talk about two months because we do have critical decision to make uh so that two months could be what the outcome could be that uh well because if today the code has impact if we can separate that impact then it be it can become a uh body for the open source uh adorability project with no production attachment and and that way that that becomes uh full report open because anybody can then then every every security issue can be reported openly because they there's no impact on on the the production system. So that's a possibility as well and another thing is that well then it become a private project and then withdraw from the from the project here. So so there are two possibilities in two months. Um, >> but isn't what what you just said, maybe I understood it wrong, right? But, um, from how I understood what you just said, it would even make more sense based on that to think about bringing that project back into incubation. Because if I understand it correctly, you have some base decisions now to do to understand in in what direction the project should go. and and and with that um the the question of of um downgrading the project to be more flexible in all that and to you know like um be more open in in the direction you want to go could be a a positive one for for the project. So, um, is it is it something where you say you don't want that at all or, um, how how is your opinion on that? >> Yeah. You're asking me, Hrik, are you asking me to respond to >> Yeah. Yeah. I would like to hear your voice on that. Absolutely. Yeah. >> Okay. Okay. Yeah. Um this is something I want to kind of get some feedback from tech as well. So this is not something we have a solution ourself and I think we want something that's more flexible. We don't want to like like that. We don't want it to be like a reporting or leave everything open right now and then stick to every every kind of for example my understanding right now is that you cannot have private meeting or you cannot have a private repo for that. Okay. So, so I think if you think that uh uh I I think Anu were basically saying that you have a dormant or you have a lab going back to a lab or you a project and project is more rigorous and spend more time and then follow the process more rigorously and then there's there's another thing for lab as well. So, so there are several things we can I'm I'm open I'm because I don't have a solution right now uh a perfect solution right now. So one thing is that we made the decision two months later if tech can delay that if there's process for that or um we can you can vote to decide you want to what will be the the best place for this to go uh so so that's the two possibility I would recommend maybe wait for two months uh uh at that time I think decision can be make the better decision can be made and also can I can bring this to the team saying that tech is going to consider this in two months then we have something kind of more solid to consider on our side. >> Thank you. Thank you which is sorry quick time check Hendrickk we have five minutes. >> Sorry. Sorry. Yeah. >> Yeah. Go on. Sorry. >> Um so so first of all thank you that you are open here. um because I think that is super important that that we can speak openly about the the different oppon um or possibilities that are on the table and from as far as I understood what what you just said I believe having it at a rep um again to establish ways on how to handle all those things understand what can be public, what must be private and and so on. I assume it's it's a good way to to do that then and I would not even see it as a downgrade maybe but more about okay we want different workflows and we need to enable that and that goes way way faster in a because as you said you don't have those restrictions the reporting to the tech and and so on so you can just move faster right because being being a a full project outside of the rep sounds good, but but comes with um with additional topics you you need to take care of and and maybe and and this is my my gut feeling. May maybe I'm wrong, right? It's just from from what you said, maybe for you it would be even better today to say, "Oh, we totally flexible. we can move in in any direction and once we've solved all those points we will come back and and and rem and get back from the from the rep states into into a regular project state. Maybe that is then the best way for you to move forward. >> Yeah. Yeah. Well, thank you Hri that good good point. Yeah. Um I know like we have four minutes in the meeting but I want to do a quick check with with the tag. I believe like the options we have today is clear. Um one is like wait for 2 months as requested by or maybe second option is we take action today that action could be that requesting smooth to act as a lab for the time being until these opens are figured out. So which option is the tag tending towards? Option one, wait for two months. Option two, take action. >> David, >> just going to ask is there a is there a clear path for a project to go from a lab back to incubation if that happens? >> It would have to be via a project incubation proposal like the way initially it was accepted. Yeah. That's what I expected. Thanks. The um you um VA you suggested to wait two months would move smooth to become a gap a huge problem for you or would that be acceptable? Uh sorry the uh can can you uh hand the >> Sure. I can I can repeat. You suggested to wait two months. Well, the tech is oh we want to >> okay why when I suggest two months I that's a time when we come back to the tag saying that yes we find huge potential for the future success of this project we want to continue on give try try our best to to to be encomp compile to everything and then try