 Okay. First order of business, Chris. Yeah. Well, the FedEx guy had to ring the doorbell. Okay. That's clearly his fault. I think the dog knows when the recording starts. Yeah. All right, let's, let's go. All right. Well, welcome everybody to the hyper ledger technical steering steering committee meeting. Everybody's welcome to participate. And the rest of our open source activities. So long as you abide by the antitrust policy that you see there. And by our community code of conduct. To be polite to everybody else who's contributing. We've got a few announcements to kick off and then we will try to wind our way through some of the pipeline decisions. No, our no is not able to join us today. And then I think we've got a late breaking quarterly update that. Some of you may or may not have been able to take a look at. So pretty light day, especially in comparison to knocking through three projects last week. So maybe we can. Do the, the big reveal then from rye. Oh, okay. So the results are in. Here is the TSC for 1919. Sorry. 2019 to 2020. Congratulations to everyone that was elected. And those that were reelected. You know, thank you for continuing your service and to the new people. Welcome aboard and to those from the current TSC who did not get reelected. Thank you very much for your service. And I turn the floor over to Dan. Yeah. It feels like probably a few words are in order there. It's nice to see that we've got some new talents joining the team. I'm certainly. I'm hoping that we can continue that dialogue now. And maybe some of the talents that isn't. Immediately. Join us. We had some discussion on the mail threads. Leading into the election that we didn't really have time to deal with formally about expanding the TSC. I'm hoping that we can continue that dialogue now. And maybe some of the talents that isn't. Immediately. Join us. We'd be again available. Should we have a mechanism to expand the TSC so that we've got. More and some. Yeah. Additional diversity there. Yeah. I agree. I mean, I'm. So I tend to fully. Concur. Yeah. I think that. That it's a shame that we're losing some. Valuable voices. I am pleased though, with the. The new diversity that we have both from a. Sort of. Company perspective as well as. Both Tracy and Swathe being able to join. I think that's great. Wish we could have more. I think. You know, I brought this up the last time that. You know, I thought we should. Think about, you know, the potential that we might. Expand the TSC and I guess there's a couple of different. You know, ways that we could go about that. We could try and lobby for a charter change and. Hold a special election or, you know. Maybe we could do something that's not necessarily. You know, requiring a charter change, like, I think. We previously talked about maybe having some sort of like at large. TSC membership that the TSC could select that's. There's, there's number of precedents for open source. Architecture or, you know, steering, you know, committee boards doing that kind of thing. Like the. You know, you know, where they had sort of at-large seats. That expanded their. Respective. It was the technical oversight board and the CNCF. And so maybe we may want to think about. That I don't know if we need, you know, Salona or. I don't know if Brian is on. I don't see him. You know, some sort of a. A blessing from. You know, from Mike Dolan or somebody, you know, from a legal perspective, can we do that, right? Without something specifically in the charter or. So I may need that kind of a review, but I'd certainly be supportive of expanding. You know, from 11 to. I don't know, you know, maybe add four or six. Yeah. I had some reservations before about expanding just because it can be difficult for us to make forward progress with a smaller number of people. But as I'm now faced with the consequence of not expanding it, it does seem more. I don't know palpable. So yeah, I think expanding it by a relatively. You know, you know, you know, I think the conservative number like four or six might be a good way to continue to retain some of the talent that we have volunteering. Absolutely. So I would ask the, I guess the new TSC. To consider. How they want to do that. Operationally. I don't know if we basically would want to rerun. That election. Or if we want to like revote with the, the previous people who were standing or I would just ask that the new TSC think very carefully, operationally about how they want to do that. Yeah. Well, that's what I said. I think we need to have. You know, I think we need to have, you know, you know, you know, somebody, you know, maybe Andy or Mike Dolan or somebody just give us a, a read on, you know, what they are, the possible is here. Could we have the TSC vote in at large members without modifying the charter? If we can do that, then that might be the most expedient and simplest way to go about doing that. And then we could have maybe a closed session. We can have some discussion. Okay. So, uh, I just don't know if that's legal. Right. Right. You know, per the charter and stuff. All right. So, uh, I'm not, I'm not going to show. Sorry. One of the pieces of feedback that I got from Brian is that he doesn't want to. Make the elections into a leaderboard. So with that in mind, I'm not going to share my screen. I'm not going to share my screen. I'm not going to share my screen. I'm not going to share my screen. Um, but, uh, Concordant condors it. Sorry. Has the ability to show what the election would have been. If you had set the winning choices to 16. Or something like that. Right. So you can play with the election results to see what it would have been. Um, that, that is easy to do. Um, but. Uh, I don't want to. I don't want to get into that. I don't want to see the top 40. Um, who wins right? We can expect, we could expand the TSC until we had like. Until. The people that you guys wanted to be on there was on there. Right. And I don't really, I don't feel that's fair. Um, so if you wanted to come up. With another way to do that, like. From the previous election results. Pick the top 16 or the top 14. that's fair necessarily to the people who voted in the last election. So it is an option, but you know, be careful. Yeah, so maybe what we could ask then of the incoming TSC is to take a look at the references that Chris just mentioned, CNCF, Chris just mentioned CNCF and what was the other one, Chris? Well, anyway, the other one that he mentioned that had done at large voting and just get a feel for what precedence is out there. Also think about what a reasonable size is to work with. My bias is smaller is easier to work with. And we can pick that up as one of the first matters in the next week. Yeah, I mean, I definitely think it should be up to the new TSC, although you could make an argument that the outgoing TSC has less bias, but it's not actually the case, it's overlapping. So, I mean, I'm kind of warming up to the thought of having the TSC actually choose from amongst the membership, although we could have another nomination stage and just make it a vote of the TSC members so that it's not as complicated and doesn't put too much of an onus. I mean, it could just be a, like I said, a closed session where we have discussion and voting. Yeah. Okay. Well, I don't know if there's more to be said about that. Well, the China is pretty clear. It says the board shall consist of, the TSC shall consist of 11 elected contributors or maintainers. Right. So, I think- It doesn't say you can't have more though. It just says it shall have- Well, I mean- Elected. Yeah, I mean, you could appoint as many, I mean, you could appoint- That's what I'm saying. I think we need to get Andy up to grow over, Mike Dohler or somebody from LF Legal or the external counsel to give us advice on what we can do. If we can't do it, we can't do it. That's pretty clear. And if we need to modify the charter, that'll take some doing, right? We have to go appeal to Brian and the board, get that through and then hold another election or something. Yeah. I mean, I'm, like I said, I'm fully with Dan that it's unfortunate that we're losing some key voices in the community that were on the TSC previously. I don't know that we're losing the voices. This is an open call, right? It is. They've lost the ability to vote, but the voices is still there. They want to be here. And, you know, we- I kind of don't get it, right? I mean, we didn't have this type of heartburn the last couple of years where people who didn't make the cut, you know, we spent the entire meeting, you know, talking about how sad we are that they're gone, right? I mean, we have new voices, you know, that were just elected, right? All right, well, I think we've sort of run the course of the conversation for now, but like I said, new TSC ideally picks this up next week. And if we can get some feedback from LF Legal on the options that will help inform that conversation ahead of time. So, with and through the remaining announcements about a month out, we've got the Maintainers Summit in Minneapolis. It occurs to me that if we're going to pick that up with the people who are organizing that, but at any rate, make sure that the maintainers for each of your respective projects, for those of you that are on the call or aware of and trying to attend that. And then the following week, we've got a boot camp in Moscow. And I don't know how long the visa process is, but it's usually longer than you would think. So if you need a visa to get to Moscow and you wanna go, you're probably better off doing that as soon as possible. Hey, Dan. And now, yeah. With regards to the Maintainers Summit, besides having people register, I think it's also important to get additional agenda topic ideas added to the agenda link. So if anybody on the call has anything that that we should bring into this, definitely add that to the agenda link. Yeah, all in all help with planning for that. It's just another community-driven activity here. There's not like a lot of staff behind the planning of this event. So maintainers, if you can put topics on the board that you wanna talk about, there's a page to do that on the event link. And then that also includes anything that you wanna do for what you think would make a good team-building activity. I'm sure that the folks that are in Minneapolis can offer up local suggestions, but it's not just limited to those people. So I'm sure there's a lot of team-building things that are available independent of city. Also, Sloane here on the boot camp Russia thing, a lot of times it's just easier to get a tourist visa than to get a business visa. We can see about getting the letters for the business visa, but the scuttle butt was from them was basically a tourist visa is a better way to go. Okay. All right, well, moving into the pipeline discussion items, it looks like Arnaud may have joined us on the call after all. Arnaud, are you in a position where you can help lead the conversation there? Take silence as a no, but you can interrupt me if you do- He may just be listening and on a plane to talk. Right. Doesn't wanna give away that he's got his phone on non-airplane mode. Get tackled by the TSA. Okay, so if we do go ahead though and go into the Project Lifecycle, I don't know why I called it Pipeline, sorry. So the Project Lifecycle, the link will take you to the right place anyway. If you click the Pipeline link, we have closed several of the issues. There are two more that are no indicated are not terribly controversial so it might be able to close on and then the item number six, that is the third remaining one that might require a little more discussion. So the first one that we've got is the criteria for a first major release and this starts to fall into the camp of what is the hyperledger way, kind of following our discussion last week about continuing to expand the kind of projects that we have, the redundancy of projects that we have. If we're gonna still have a technical brand, so to speak for hyperledger, you know what is the hyperledger way and so having some level of quality to a first major release is important to that. I haven't previewed this. I don't know, looks like the last updates were August 28th maybe, so not a ton has happened in the last week or so. Does anybody have any comments on how complete this is at this point? I was just gonna suggest, why don't we just wait for our note to be available and discuss it then? I mean, bring up the people should review it and get their opinions noted, but... Yeah, so we don't have to take it to a vote today, I guess. That's a good point. We may as well use some of our available time here to discuss issues if people have things that they believe are still open on this draft resolution too. Hey, hi guys, can you hear me? Yes. Okay, I'm in a taxi, so bear with me. But if the connection is good enough where I can briefly try to describe what this is about, I mean, I think it's fairly non-controversial, the issue had to do with, what does it take for a project to qualify for first major release, given that there's quite a bit of churn involved, including from the links foundation, the staff has to get involved, do the security review, and then there's quite a bit of PR and all sorts of things related to first major release. So this issue tries to define some criteria that can be used objectively. I mean, some of them may not be seen as super precise, but I think it's still a step forward from where we are today, where we basically have no criteria whatsoever. And so I tried to, there were some comments and then there was, I made some updates and I haven't seen any further comments. So I got the feeling that, okay, this is actually probably acceptable. And so I would be happy for the TSC to agree to this new definition of what it takes. And of course, as always, if down the line, we find that there is some imprecision or something is missing or doesn't work, we can always fix it, right? So. So how to, one of the things that's missing, how do we feel about some level of quality as a requirement? We are supposed to be doing enterprise level work. Yeah. One of the criteria that we had for the fabric first release was to have the set of JIRAs triaged and reviewed and that there should be no high JIRAs that, remain in, for the release, right? They had to be medium or low and certainly no security defects. So, I mean, again, I mean, I think some of this is somewhat subjective, right? Because you're, people can sort of fudge that a little bit, but certainly the intention there was to ensure that, you know, we weren't putting out something that had significant issues at the time of the release. That doesn't mean that there aren't going to be some that are uncovered, but, you know, certainly from whatever testing is done, there shouldn't be any major defects. Yeah, I mean, even in terms of the goal, right? There's some text, I don't have the text in front of me right now, but it's something about, you know, you've achieved the stated goal by the project and of course, this is kind of wishy-washy in some respect. Sure. So, I mean, back to Mark's point, it's true that, you know, it's very hard to judge the quality of the project, right? The software, but, you know, I think that's something we have to live with until somebody, you know, comes out and say, wait, this project sucks, I'm sorry. You can't make that a major release. I don't know that we would be in position to really make the call. It doesn't all software suck. That's what I'm talking about. I did find the text in there, it's in part five of resolution two. That's B and C. But yeah, I mean, right, the same thing with, you know, documentation, right? There's never enough documentation. Exactly. Right. Exactly. How do you imagine that? I wanted to jump in here, this is Dave, excuse me, looking at these, I just wanted to state that items one, two and three and six are all like on-off kinds of things. They're light switches. These are easy to measure, easy to know when they're completed and that it's really numbers four and five that would demand the advice and consent of the TSC, right? Does that make sense to everybody? Cause like one, two and three are just obvious. Yeah. Although it should say a license scan was completed and all issues, you know, medigated, right? That's correct. Yes, yeah. That is correct. Well, we can make that amendment to the text. Yeah. I think we should just finishing the scan, doesn't it? Yeah. And it does reveal a whole bunch of things we've ignored. That is true. That's a lot of I's and T's to take care of. No, but there is something else about the issues that it says that the maintainers are comfortable with the issues or something. I forget the text now, but so there is another piece that talks about the issues. There's no major issues open or something like that. Maintenance of remaining open bugs and agree on severity priority. Exactly. So I think with the two of them coupled, but we can clarify the, you know, make it explicit on the scan. Yeah. I think we've made it that so it's explicit now. It says in all issues were resolved. Thank you. I think that's good. And I'm also going to update it to also say or exception has been granted by the legal committee. Yeah. That's good. I like that. Yeah, I took that as a kind of resolution. A question about the first major release, did that get decoupled from necessarily being 1.00? I see there's a comment from Sean and part of that about trying to adhere to SEMVA. Are we still expecting 1.0 to be the first major release? It depends on, oh, go ahead. Arno, sorry. No, no, no, it's okay, Chris. I mean, it is indeed now specified in there and to me it's kind of by design. I didn't want to get into that. Yeah. I mean, if you brought a project in and it was already at some version number, even if you renamed it, you may want to, you know. So, I mean, the example with this is, with Go, as people move over to modules, I mean, there is actually some leeway with the first two major releases and maybe it's compatible, but you start to break some of the ecosystem tooling if you can't go, like, so we're, for example, on borough, we're making breaking changes on minor releases and we sort of say, yeah, okay, but it's a little awkward. But do you have a first release though, right? Silas? All right, sorry, I just lost my mute button. We have, we don't have a 1.0. Are you done? We're on 0.0. We're like 0.2 to what we've done here. But I think for zero, it doesn't matter, right? Yeah, for 0.3 to 0, I have to go back and read December text again, but I think for zero, you can add breaking changes. Are we in December, you can answer. Under the Go module system, we ought to be pushing out our breaking changes onto a version one and a version two. Okay. So then you go to mod stuff. Yeah, so this phrasing doesn't prevent any of that. I think it's, we specifically called it first major release because we knew that some projects might come in with versioning metadata already set something higher and making them rewind that could cause things to break. The main thing is here's your first big announcement that you're gonna make through Hyperledger. You're gonna be applying the Hyperledger brand. Is your project of a suitable quality that it should get to do that? So how I'm gonna be interpreting this too for the subjective things is when a project comes and says we're ready, that project should know that we're gonna go take a look at these items and we're gonna give them feedback. So it is totally subjective to say whether or not the documentation is sufficient, but I think that if people are going, know that it's going to be inspected, they're gonna hopefully think about it a little bit more if they weren't already caring about that. So I'm satisfied that there's nothing that is too onerous on here and that we've got enough flexibility to account for tool projects as well as framework style projects. I had a question for Dave. Excuse my ignorance, but I'm assuming that security scan looks for CVEs and things like that as well. Yes, that is true. So the security scan is when we hire an outside security firm to do code review and network fuzz testing and vulnerability analysis and they focus heavily on the interface between code and underlying crypto code because that's where a lot of bugs come from. So if you wanna talk more about that at length with me, I can go through all the criteria, but it's pretty extensive. And all you have to do is look at the technical reports that are published underneath our security scans to see the level of what our auditing firms go through. All right, cool, thank you. Any other clarifications needed or should we move forward with a vote here? Hey, I had one last thing to say about the question of it being 1.0 or not. Bezu is doing a 1.3 release in September and we're already, like I was talking to them yesterday about doing a security audit port as their first major release as part of Hyperledger. So I just wanted to throw that out to the TSC to kind of rationalize about this. I think it's not necessarily 1.0, but it's like the way I've been thinking about it is the first major cycle of applying the Hyperledger way. Yeah, but they're past 1.0 and- I think we have to be somewhat careful about this because one of the criteria is active, right? Ooh, yeah, you're right. CII and all that kind of stuff still applies. And yes, a security audit typically is done beforehand. Right. It's gonna take a month or so, right? Even if we can get their attention. Yeah, it takes a couple of months. I'm with Bezu. We did a security audit about a year ago with Trail of Bits, so we have had one. We just haven't had one in the past year. Yeah, well, we did two with Fabric and we still did one through Hyperledger. Okay. Right, an independent audit, right, is still a requirement. Yeah, I think- Right here. I didn't mean to derail this. Go ahead, Troy. A security audit, what's the scope of the security audit? I mean, a project has some projects that have frameworks like the DLT along with various clients or SDKs. Thinking about the ARIES project, which doesn't necessarily have a DLT backing it. It's more of peer-to-peer clients. I was just kind of curious how the scope of the security audit might look based on these different variations of projects. I don't wanna derail the conversation. Can we take this offline, Troy? Yeah, sure. We'd happily go into all of it. The short answer is it depends on the goal of each project. So you're right. Fabrics are tested or like DLT platforms are tested differently than say libraries. A question on the criteria. Was it not the case at some point that we had the TST approve first major releases? Certainly with Fabric, we did, right? We brought all the evidence to the table and to mother, may I kind of think? Yeah, I thought we had added that at some point. Maybe, I don't know, last year, it wasn't. I don't see it here. Maybe I'm missing it. Yeah, I don't know if we added it formally to the processor. And I know that for the 1.0 release though that we did go through a review and... Are you saying that in what we've got written here, we're lacking that? Yes. The thing that the TSC will actually vote to approve it? Yes. Yes, we are missing that. I'm happy to fold that into it, but technically it's a different issue that is related. This issue is about the criteria for our first major release. How you use those criteria whether it is used for a TSC vote or not is somewhat orthogonal. I think we didn't have it documented on the lifecycle process, Tracy. I think it's that... That's what I'm wondering too. Yeah, it was... So it does different say that they do have to seek the approval of the TSC. This is where the lack of consolidated decisions by the TSC is hurting us. It'd be nice to have a record easy to search for that because I agree, I think that decision was made sometime in the past when we realized, okay, those first major release implies quite a bit of expense, you know, and we then do that lightly. So, but I don't know. I cannot point to a resolution, so... Well, yeah, but what Solona just reminded us of is that it's actually listed on the lifecycle page. So if you go to the existing lifecycle, it does say that the TSC has to vote. I agree. So I think we are covered there. I was viewing this as what needs to be done before the TSC considers it. Yeah, yes. That makes sense. And we had a problem in that we were all having... When we were doing the voting and the approval process, we didn't have clear definitions for the TSC, much less for the incoming projects. So that I thought was the inspiration of this is to sit there and to be able to take some of the stuff from the project lifecycle and make it better defined. It might just be worth noting that in this. I mean, if we're going to approve this, that this is what needs to occur before the TSC will vote. Hey, Arno, can I propose one slight change to issue two? Can I restructure this so that the technical objectives, the on-off ones are regrouped at the bottom here under the project has met all technical objectives. And that includes CII best practices, the bad, right? The security audit with all of its sub items. So that's number two. And the license scan number three, plus the release code notes are available. Does everybody agree with that? Cause these are all just like a tick list of technical objectives that are straight. That's totally fine. I mean, it's a tutorial nature and it makes the document easier to use. That's fine with me. Yeah. The only reason I put release notes at the end was that's sort of the last, one of the last things you do. Right. So I'm not going to change that order, Dan. I'll just, I'll just group all these technical things at the very bottom and update the document. Okay. Cause I think that makes things clear because then items one, two and three would be like all of the subjective stuff that requires some interaction with the TSC. Updating now. So if you can reload now, you can see my changes. Okay. Does that look good to everybody? Maybe technical objectives for the release, technical criteria for the release. Okay. And then. Oh, sorry. I was on mute. Sorry, Dan. So one of the thing that I just thought of that's not actually here, it's not just release notes, but a change log. Oh, I'll add that Chris. Yeah. To the bottom here. Typically the release notes are pros and the change log is all the commits, right? All right. Change log is captured also, Chris. Okay. And then I added a line at the top saying that, you know, before you bring this for a vote, you should have fulfilled that stuff. All right. Well, I move that we go ahead and take a vote on this. Hey Dan, can I ask a point of order? Sure. Existing TSC or new TSC? Existing. We confusingly somewhat decided that this was still an existing TSC meeting either before, during, or after the last meeting. No worries. Right. So there was a little bit of an off by one error there and that communication was unclear and that's probably on me. But the new TSC doesn't exist yet because they haven't elected a chair, et cetera. And the thought was it would be a little bit rude to have the election in last night at five Pacific and then ask the new TSC to be seated and voting and stuff at seven AM Pacific the next day. So the new TSC starts next week, not this week as previously announced. Well, the new TSC starts at the end of this meeting, right? All right. To be clear. Well, sure. The election for the chair starts. As far as this vote, though, do we have someone willing to second that motion? I'm just reading what's written now. I'll do the seconding. This will be my last chance to second. Don't give up hope, Silas. I also haven't voted no for anything. So can I second and vote no? I'm not sure. I don't think there's anything blocking that. Vote recorded. When you second it, it just means that, you know, you want to bring it to a vote. So you want to hurry up and kill something. You can do that. All right. So we've had a motion and a second. So let's just do this by voice all in favor. Hi, yes. Hi, hi, hi. Any opposed. Any abstaining. All right. Draft resolution two is accepted. And we've got one more that we might be able to knock out here. Waiting for my page to refresh here. Yeah. So there's a related issue, which is OK. And then what, what about the next major release? And so there's a very short proposal to basically say the same criteria applies plus the fact that, remember correctly, Sam Ver needs to be respected. And I forget there is another one. There is one technical issue here that the TSC has never addressed, which is do we redo security audits for every first major release or sorry, not first major for every follow on major release? Now, up until this point, the answer has been yes. Or the assumption has been yes. Couple projects have been audited twice, right? Fabric specifically has been audited twice. Once at 1.0. Once again at 2.0, but also included the 1.4.x long term stability release. And I wanted to bring this up because this has significant consequences to the hyperledger budget because these aren't cheap. And absent of any clarification from the TSC, I aired on the site of caution and said yes. But this is the chance to set the policy going forward. I agree with the way that you aired. I wouldn't even call it an error. I think most major corporations for enterprise class software do security audits for every release, right? That the TSC is going to vote on the first major release. We haven't seen anything like this or anything after that. So it may be more that needs to be settled on that front. Well, this is why it would need to be brought to the TSC and discussed because the TSC is going to have to decide are we going to commit marketing and auditing and all that kind of stuff. Is it ready for a next major release, right? Imagine a project that does a 1.0 and then wants to do another 1.1 and asks to be a next major release with all of the big push and everything. The TSC might say, well, it's not really a next major release, right? I guess I'm interpreting major here to mean a major version number in a Semver context. So it's sort of a weird initial state when we've got a project that's at 2.7. It's their first major release with Hyperledger that it's coming in at a strange version number. But everything after that should follow Semver for this process. And that's the way that the resolution is written. I agree. I guess if we're considering Bezu again, is it now expected that Bezu approached the TSC for their 1.3 release and asked basically for permission to be considered a first major release or a major release and get all that and what that all entails? Short answer, yes. Though this issue three is sort of independent of that, this would be more for they've gotten through that 1.3. Now they want to do a 2.0. Do they have to do that over again? Right, yeah, you're right. And what happens if 2.0 follows quick on the heels of 1.3? Yeah, so we could definitely run into some sort of budgeting problem where if somebody wanted to do a major release every month, that would just be weird and problematic. But we can probably deal with that when we come to it. I'm sure that the TSC wouldn't want to vote every month on the same project doing a major release. I mean, I think that's not actually completely facetious is the point because, I mean, some software does do rapid release cycle. If we are saying that in this secondary point, the major does refer to major timber. I mean, that might happen. Yeah, I certainly agree with that when we come to it. Does this get the TSC into policing the application of timber? Like, was that really a breaking change? Or was that really right? I mean, because that kind of, I don't think that's really tenable for the TSC to be policing everyone's version numbers carefully. Yeah, and it's also something though that's just subjective when it comes down to it. So it's a problem if people are trying to do a major release with press announcements on a monthly cadence and the TSC should shut that down, because that would be appropriate. And otherwise, I don't see the need to try to put informal language one way or the other on that. It's good for that reason, if nothing else. Whether the TSC actually gets in dirty into figuring out whether this is true or not, that's a different question. Yeah, I mean, I think I kind of agree with Dan's sentiment. I don't think we necessarily need legislation for this. We definitely don't want to discourage people from doing a major release when they have a breaking change by giving it this external semantic meaning. As long as we can communicate that in a way that the people realize that they won't necessarily have to jump through hoops and it doesn't have to be a big press release every time they bump the major number, then that's fine. So if we were done with this part of the discussion, I had something a little more tangential dealing with versioning, though. And it came up when we were talking about Bezu, how Bezu's coming in and they're at like 1.3 or something already. And so in general, most of the time, a company product follows the upstream versioning number. And I'm wondering if the tail is wagging the dog here. If the TSC needs to be concerned about that or not. And I'm just bringing it up for discussion. I don't feel strongly one way or the other. But do we need, you know, typically, you know, the upstream goes first and then a product comes out shortly thereafter. Do other people have thoughts on that? I'm not following you, actually. Well, so when Bezu comes in, right, are we taking, are they going out at whatever their product version is? When they do their first hyperledger release, right? I mean, I work for an upstream first company, so maybe it's different. But, you know, everything Red Hat does goes upstream first. So, you know, we'll put kernel changes in and they won't show up in our kernel for six months. I don't think there is an upstream for Pantheon. I think it's just Pantheon will just become it sounds like you have in mind a downstream product version of a repackaging of Bezu. I wasn't aware of that. Well, their upstream version will be Bezu, right? Right. So we're going to let them keep their existing versioning number just because it is a pain to go backwards with versioning numbers because it can break different kinds of build systems. But from the point that they became a hyperledger project, they are the upstream Bezu Ethereum client. And so if there's companies that are contributing to Bezu, but also releasing their own products, whatever product versions they release are, you know, that's up to them. Yeah, I mean, right now we're at 143 with Fabric, although I think the product from IBM is 2.0 and using 1.4.2, I think, but they're not necessarily connected. Okay, like I said, I'll go ahead. No, but I do think the Bezu case should be put aside and this question of, you know, should the first major release be always 1.0 or can it be something else should be discussed independently? I do feel like it should be 1.0, at least by default. And then we can look at specific cases if it really causes headaches and breakage, we might release that. But the can depend on the issue that we have in front of us. So I, you know, I would like to move to close the issue that we're facing about the next major release and then we can spend more time and maybe raise a different issue as I was saying earlier as to what should be the first major release. Okay, is there a second for the motion to vote on issue number three, draft resolution three? I'll second. Wait, where is the draft resolution for three? On the wiki. Thanks. No, it's in the same, it's in the same, sorry, it's in the same place. Yeah, I know that. I was looking for it on the screen. Go hit your back button and then go back to the issue. Sorry. I'm never really sure how fast I should, I don't wanna get people whiplash when I'm clicking around because I have like four other browser open so I don't wanna like click or click or click and make you guys see so many things. Here you go. So it's been seconded? If it hasn't, I'll second it. Yes, yeah, I seconded. Okay. Sorry, Chris. It's okay. I just, I was looking for the text to read. I was just like, wait. All right, voice vote, all in favor? Yeah. Aye. Sure. Aye. I mean, aye. Aye. Any opposed? Any abstaining? All right, motion passes. All right, we've got about three and a half minutes left during which we could hit the issue six or just kind of, I guess there was some other discussion on the version numbering. Well, maybe we should continue on the version numbering if people are interested because the other issue that is left, you know, there are several related questions but they all relate to the question of subprojects which I think remains highly controversial. So I would invite people to look at the week again and then start digging into the different questions and I honestly haven't made much effort to try to, you know, consolidate the input that has been put in so far. I promised to do that as soon as there were a chance and we have closed the others. Yeah, we definitely don't have time to talk about it in depth. So let's go ahead and talk about issue six next time. And if anybody has anything important to say on version numbers, go ahead and hit that now. You just said the ball pretty hot. Best time to take care about the version. Oh, wow, I don't know. I wanted to, just since we're out of time and there was a question from Zippin, I wanted to show you, this is the interface that you see if you're a manager in GitHub of a project. So this is the result of an automated security scam. So there are, the question was, can we do something cheaper, right? And like we have all the projects have this in GitHub and you can look and you'll see some of the projects have a very long list here and some don't. So we are actually doing that in addition to the security scans that Dave was doing. And also I also wanted to throw in here, Zippin that the CI CD effort has pretty significant implications for quote unquote cheaper security, right? We can do all kinds of automated things if we can settle on a CI CD solution for all the projects and start pushing them in that direction. So that has always been my dream is to get all of our projects on an airtight, reproducible builds kind of system where we have a whole bunch of security checks imbued into that. You got to get some more exciting dreams, Dave. I just lack imagination, honestly. That's really what it is. All right, well, we're at about time here. So I think I already said nice things about everybody last meeting and at the beginning of the meeting but it doesn't hurt a little more time to say thanks for all the time that the outgoing TSC members have put on this. And I know a lot of you will continue to participate in one form or another. Like we talked about at the beginning, this is an open community and we regularly hear from everybody whether they are TSC members or not. So thanks again. Yes, thank you. Thanks, everybody. Thanks, everyone. Joe. Doug had to get the last word in. Yeah. All right, bye, guys. Thank you. Bye.