 to where we get, you know, how far we, so let's get started. All right. All right, welcome everyone to the TSC call. I see only a familiar name, so I assume you all know this is public call. Everybody is willing, is welcome to join and contribute. And this is not a figure of speech, by the way. I mean it. And so you all know the antitrust policy notice by which we must leave it. And the code of conduct, of course. So let's get to the agenda. And Gary has joined, so we have a full house, pretty much. Not quite, but enough anyway. All right, so there is some announcement that was inserted in the agenda and I will let Dave talk about the TSC election nomination. Thank you, Arno. So we are nearing the end of the nomination period for the 2020 TSC election. It closes at the end of the day, well I'll say midnight on the 19th. So this is our last chance to go and recruit people for nominating themselves or to nominate people to run for the TSC election. Once again, the way to do that is to email election at list.hyperligio.org and say, hi, my name is Such and Such, this is my email address and I would like to run for the TSC. We are currently sitting at 14. I haven't looked at my email yet this morning, but we have 14 nominations for 15 seats. So we still have one totally wide open seat. And yeah, this is our chance to encourage the people we'd like to see in the technical leadership of Hyperledger. So please spread the word. Okay, Arno. Thank you. So the next piece here is mine. This meeting will change soon. All meetings will change soon. Zoom has changed the way meetings are done. All meetings shortly will have to have passwords. So you will be getting new invites to pretty much every meeting that you have. So I'm gonna after this meeting, I'm gonna cancel the TSC meeting and I'm gonna replace it with another invite that has the new information. So that's just heads up. Can we wait a few weeks for the new TSC to be in place to do that at the same time since you're gonna have to update the... I think it's the 25th is when Zoom starts enforcing this. So I don't have control of when Zoom flips the switch. So no, not really. Arno, I just wanted to announce I just got one more self-nomination for the TSC. So we have 15 candidates for 15 chairs. So unless we get more nominations, it's pretty much a shoe-in for everybody. Yeah, we haven't really planned for that, but I guess if that's really, if that were the case, we don't have to have an election per se, right? We can just declare it or even... We still need to have an election per the charter. So we'll actually, what, the TSC gets to select the... Yeah. What should we do? Let's do this once we find out whether or not we have one more person. Yeah, we'll wait if we face that situation. Sorry, Brian. No, that's it. Just saying, we'll deal with it then. Yeah, I'm sure the charter outlines what to do, so. All right, thank you. Anything else on the announcement piece? All right, if not, moving on to the quarterly reports, I assume you guys saw, we just received a report from the borough project, Simon sent out an email to the TSC list. It's kind of big in the way he described the situation. He said he might join next week. I don't think we should get too much into this now, but we want to make sure people are seeing it. And I have to say, I appreciate this, you know, how candid he is in his report. And so please have a look. We are missing Avalon, but, you know, it was due today, no big deal. Hopefully we'll have it by next week. So that brings us to the issue at hand. We have one real issue we wanted to have this call for today, which has to do with the request from the Bezu team, hereby represented by Daniel, to be allowed to use Cal there instead of SEM there. There was a bit of, so thank you, Daniel, for putting the proposal on the wiki. There was a few comments. So I know that quite a few people have actually looked at it and commented on the wiki page by far not everyone, but, and then I do want to point out that Daniel also posted, he actually submitted a PR against the taxonomy, the release taxonomy document on GitHub. It's a draft PR. It constitutes a slightly different, I'm sorry, it's a draft PR against my own fork. So it's not formally yet. Oh, yes. Okay. Yeah, yeah, it's not been submitted. You're right. Thanks. But it's slightly different because it goes further. The proposal as described on the wiki is to allow Cal there in addition to SEM there. The draft PR that Daniel put together goes beyond that in saying, okay, SEM there is the default. Otherwise, use something else, but make sure you define it and there's a set of criteria. But I just want to highlight and I put that on the TSC channel that it's a bit different. It's broadening the proposal. So who wants to say anything about this? I think, I mean, I can summarize the thing I'm saying, well, so Daniel explained already last time kind of the why they feel the need to change. I think the reaction I've seen is some people feel like it's not clear the change would solve the problem they have. And I will let Daniel speak to that. The other part was Dan came up with some suggestions to use some hybrid model. And then there was a suggestions which I guess the draft PR is defined with by Gary to just give up on dictating the release taxonomy. So that's, we have a whole range of possibilities, you know, facing us. So Daniel, why don't you explain a bit more? Yeah, sorry. You were going in the exact direction. I was going to ask that Daniel take the floor and give the next question. Okay. So Daniel, I think it'd be good to explain why you think this would solve your problem, especially the caliber at least. Right. So caliber is a numbering convention for releases. It's getting a lot of traction in various places. If you've ever used Ubuntu, you've been using a piece of software that's been calendar version. And other projects have rather than semantic version rather arbitrary numbering systems. The Linux kernel is famous that every so many releases, they just bump the Mac primary never because that's what they do. So my initial proposal was very focused on just say, let us use caliber and let us give some reasonable definition of it. And I wrote down what the issues were. But as I was reading and I think it was Nathan George's comment or Gary's, I realized that rather than specifying it, perhaps we just need to specify what a release policy the concerns or release policy needs to address. So that's what my point of my revision is. As I say, your default is Denver if you do nothing. If you want something else, you need to write up a policy and document it. And it needs to have a clear reason for clear philosophy of what your numbering is. It must also address forward and backward compatibility. And there's a couple of shoulds that you should use the tags because those are easily understood and you shouldn't just name it off characters in Toy Story because that confuses everyone. But those are two or two or shoulds that the two musts or that must be documented and sensible that it must address forward backwards compatibility. So, if we were to go with that in basic, we would probably go with a year or year dot quarter quarter release. And those two numbers together would represent where backwards compatibility is not guaranteed. And the second number is where we would introduce new features. And if we ever did, I mean the third number is where we'd introduce features and if we ever did a patch that did introduce features that was like fixing a critical bug, we might do the fourth number. So that would be the Bayesuit numbering. One of the reasons why this is quite interesting to us has to do with Ethereum 2.0. There is a bit of concern that if we do a Bayesuit 2.0 and it's an Ethereum client, people will say, well, does it support Ethereum 2.0? And it doesn't because it's wildly different. Ethereum 2.0 is just a proof of stake system currently that's being released possibly by the end of the year. So by going to a Calvary system, we can rather than having everything be one dot, a billion, we just use a numbering system that reflects the current year and the release within the year. And it goes up at a sensible pace and it's got a reasonable philosophy as to when we increase the major number, which would ideally be the year. So that's the essence of the proposal. That's what Bayesuit tends to do is to go to a Calvary type version, but as far as the general hyperledger policy, maybe the easiest thing to pass would be to say that you must define it, but you need to define it and it needs to handle backwards of forward compatibility or you should use Semper if you're happy with Semper. All right, thank you. Any reactions or questions? I think Chris has his hand up. So again, I'm not at all clear how this solves your problem, but that said, an argument for why we chose a strategy as opposed to really your own strategy is for some consistency across the hyperledger landscape or greenhouse and so that people could not be confused, introducing additional approaches letting each project essentially choose its own only further confuses people looking at hyperledger and looking at the SWAT feedback from the member summit strongly suggests to me that the confusion around things is one of the biggest impediments that we have. And so I'm not at all clear, given that I don't believe at all that this solves your problem that we should stay with what we chose, I don't know, four years ago, whatever, five years ago. I don't see a compelling reason to move off of it. I don't think we're doing a good job following it because no projects define their public APIs and there's no strict enforcement of my feature as, of course they do. Maybe they don't define their public APIs. Fabric has its documented. Is that the only one? I don't know, but you said that none of them do. Yeah, I mean, I think we, yeah, I mean, on the fabric side, right? I mean, but again, I mean, part of my point was but we have a lot of reasons why we have to do that. And this is going to be similar to, Dan Oye, you know, you have similar situations too, right? I mean, but yeah, I mean, we do do the compatibility. We do denounce like breaking changes in one case where we had a security violation and things like that in the release notes, but we're pretty strict on that, right? That we don't break stuff across the two-digit you know, boundaries, right? We're not as strict on back porting releases and dot releases sometimes, but we are on the compatibility one, but I guess anyway, I'll, so that part I think is fine, but. So the backwards compatibility is an interesting point. We generally don't do multiple release streams as well. So if we were to stick with one five and one six and one seven and one 2000, that might imply that, you know, you can have some expectation we might support older versions, which very much fabric does, but Bezu, it's because of the nature of main net Ethereum, there's one main net that we need to be compatible with and we can't support multiple streams with backwards compatibility because there's one current chain definition we must be compatible with. I think if you had enterprise users for Bezu who ask that you issue a patch release on an earlier branch, even though you've main net has moved on, you'd probably take that option, right? You'd create a, even if main net and everybody there was on 20.4, if somebody was on 22 and there was a assert notice published, you know, there'd be presumably networks who it might lag by a few quarters just because upgrading everyone is tough. And, you know, then the Bezu developers can make the choice of issuing a patch release on an older stream, right? Right, we can, we haven't done that yet and I think we would give them a bit of pressure of it should be backwards compatible with your genesis flags to go back and do the same. But you would issue a 20.2.1 or 22.2. And even though it was the fourth quarter of 2020. So what we would define as it would be the year-to-year and then the quarterly or whatever breaking level release we would do. So it would be incremented by one for each breaking release we do, probably three or four year. That's a process for all the users too. You wouldn't force users to go past a breaking release just to get a security fix. And if it's a security fix, we probably would. Yeah, so that's a good point. I think that's the main concern from an enterprise point of view is, you know, that enterprises do value that stability and there's substantial cost for the upgrade. Of course, it swings too far in the other direction. Sometimes we still have, I think too many users out there on old versions of some of our releases. So nudging them forward is great, but from a security and pushing out responses to certain notices and that sort of thing, kind of point of view, just knowing that that's an option there, that Calvary doesn't discourage that is good to know. You're right, it doesn't prohibit it. And in security, I didn't think about that level. We would put whatever passes out in production. It's non-security that we would drag our feet, probably ultimately do it if they're persistent enough but strongly encourage them to come up to mainline. But to a degree, right? I think it also depends on, but this is where, you know, I guess, yeah, I think that's where, you know, having the options didn't make sense. But look, and I know I'm like sometimes a broken record on this, right? But open source is not the same thing as commercially supported projects. And that's where I always like, you know, come down to the thing. I mean, yeah, so people can choose that and you know, the relationship of, you know, consensus and teams to Vesu, right? And they can choose how or whatever it becomes, Quorum or I wouldn't figure out what your product name would be, right? But it's up to them, right? I mean, we choose like, you know, mainly to keep things from a simplicity perspective, right, across the fabric community and working with like, you know, Oracle and others who do that, right? We try to, you know, we try to maintain the same thing that we're committed to doing from an IBM perspective because it's stupid to, for us to maintain forks and branches and whatever internal and IBM and all this aggressive stuff. And I'm fundamentally lazy, right? So we choose to do it that way, right? But you have other places, right? That are more confusing, right? So like Red Hat, right? You know, like, I mean, Red Hat has a similar thing, right? Which is very confusing for people, right? It's better now, but like, you know, Red Hat had a numbering scheme that was like, you know, OpenShift 311 was like Kubernetes like, you know, 111, right? And 3.9 was like whatever, but then it was never upgraded. Now they have a strategy where they have 424344 and those map to different Kubernetes versions, right? Like 1.13, 15, 16, 19. So I guess I always get on this thing that everybody assumes that everything that comes out of here is like, has to be managed and maintained and supported like it's an enterprise stuff. And that when an enterprise customer chooses to use open source that they're gonna go get this same level of thing as if they got enterprise support. I just disagree with that as an assumption that we should be propagating to people who consume our technology. All right, Dave has had these hands raised for quite a while. So let's get to it. Thanks Arnaud. All I really wanted to say was that I like Dana's idea of having a defined release policy. And I just asked that that release policy include some language around promoted releases as per the rules for promoted releases. Those are special and it causes the hyperledger community to spend real money on security audits and marketing and all of that. So if we do have policies, we need to define that so that we know when to ask for promotion and stuff and everybody knows what to expect. That's an interesting point because I don't think the current policy says anything about that, does it? Yeah, I thought that was maybe the truth. Promoting is defined as a December requirement. Yeah, correct. There was a, you know, hey, in general hand wavy, you know, major numbers were promoted releases, but we've seen promoted releases for fabric to 1.4, for instance, and there's one for 2.2. So yeah, I just wanna, I just wanted if they're gonna do like Calver or something else, just I guess maybe they don't need to explain how it ties to their versioning, but just what they expect to do, yeah, nevermind, you're right, there is no December requirement. I retract my statement. We can just go with, hey, we want this to be a promoted release and petition the TSE for that. Okay, so I have to say, I mean, I haven't expressed myself on the proposal. I, you know, I'm kind of in two minds, so I'm not going to make much of a difference, I suppose. You know, on the one hand, I agree with, you know, sensitive to the point that Chris talked to, which is, you know, we don't share that much stuff between the project. One thing that we've been trying to do is have more homogeneity or harmonization between the different projects. And this is kind of what, you know, going in the opposite direction. At the same time, I also feel, you know, there's no, I mean, there's no harm in and of itself if a project wants to use Calvair. I'm not sure that, you know, I would jump the gun and open it all up all of a sudden just because, well, then, you know, because we have two now, let's, you know, allow for anything. I mean, we, I'm not sure, you know, we need to be that blunt if we decide to open up a bit and say, okay, you can use either same there or Calvair. At least we have two well-defined entities. If we say something along the lines of what the draft PR that Daniel put together, you can use whatever you want as long as it's documented, basically. I'm afraid that's like, it actually puts a burden on us to then check that the projects do live by this. While if it's just a flag, you use Calvair or same there, it's still pretty simple. So, and you know, I'm happy for to stick to Calvair and same there for now. And if somebody came up with something else, they really want to use and they have a good reason. They can always reopen and we might add that to the list down the line, but I'm not sure there's a need to open it all up, but it matters. So I'm kind of like, I'm not sure we should do Calvair for the reasons I said, but I'm open to it, but I'm not so open to, you know, leaving it completely open. Totally agree. So there are quite a few people we haven't heard from. If I might, again, I'm in the uncomfortable position of being unable to raise my hand here. I, you know, I've been really upfront about my strategy internally about pushing everything to the edge, pushing decisions to the edge. I understand that this is becoming surprisingly contentious, but I would just ask the TSC to consider whether they really want to be involved in every little decision like this. Anyway, I'm done. Well, presumably it's not a little decision. So there's a lot we don't get into, right? Sure. Okay, but we haven't heard from people like Tracy, for instance, who commented on the Weki page, but, and I see Sweta has joined us. Welcome. Yeah, Arno, I'm kind of in agreement with you, right? Like I feel like the PR is too open. You know, I was somewhat of the mind, I guess, coming into this, that, you know, we'd probably allow Calfer, even though, again, like same as you, right? It's going against the consistent nature. Like it means having to learn another numbering scheme for Hyperledger project. And I also, I think Nathan's comment on the chat, right, about what we're really concerned about is the stability, dependability, knowing like what it means when something dot, something dot, something happens, right? Is it just a minor fix? Is it a major fix? Is it a breaking fix? Those are the things that people are concerned about. And I guess with something like Calfer, I haven't yet been able to wrap my mind around exactly what each of those things means. You know, how do you number in Calver? Cause when a minor fix happens versus a major fix versus a break fix, right? Like a new year doesn't tell me that's a break fix. You know, a new quarter doesn't tell me that's a major fix. You know, it just, there's nothing there that maps in my brain to what we currently have within Hyperledger. And so I think, you know, that's a, that's an education, an additional education that we have to do to users of Hyperledger projects. All right, thank you, Tracy. Anyone else? Nathan has his hand up. Yeah, Nathan. I think it's easy to read too much into version numbers. Users of software usually have to test open source packages to know whether they're gonna get what they expect or not. Because if your use case is different than the main core project maintainers, what they consider a minor change might be very significant to you. So in projects that I've participated in that have used Calver in the past, it hasn't really disrupted or changed much in terms of the dynamic of the project. My interest here is that we still are promoting and preserving that culture of stability and dependability. And using a version numbering system that's somehow rational that, you know, the maintainers can have a civil discussion about whether a version should be revisioned or not and doesn't turn into a food fight. So I don't have any problem with Calver. I do also like what Dan's saying of, we probably don't wanna just open it up to any possible versioning number scheme because we want something that is familiar or comfortable for the general open source community to consume. And both Calver and Sember are broadly enough adopted and supported that when people see those version numbers, they'll be able to figure it out. So, you know, if they want something else, I'm happy having someone say, here's how we wanna do it because maybe someone will invent a new something for that we haven't thought of yet. But that's what I'm hoping we can move forward with, but I don't know where everyone else is. So. All right, thank you. Anyone else? Yeah, I know this is not just my hand. Yeah, go ahead. That's fine. Yeah, personally, I'm not a big expert with these two things, but I was feeling from another prospect. So, from a blockchain point of view, what it means for an adopter, an adopter when there is a versioning change or there is a bug fix, even a bug fix can produce a fork in the network if the rest, if you don't tell me how to upgrade my network to the new version, even a simple bug fix can create a fork in the network. So, what I personally will be concerned is, which are the rules? Do we make sure that when you really, when this project are releasing a new version, are they telling the people how to upgrade the networks? How to make sure that if I have an Ethereum network with the nodes of different versions, no matter what's the versioning or the meaning of the version, but they will not fork. I guess that's the most important thing to me for a blockchain system. Repeat, even a simple bug fix can produce a fork if the network is not upgraded properly. All right, thank you. We also have the hot on the queue. Hey, sure, thanks. Yeah, I was going to sort of, I guess, agree with Dan Middleton here. You know, I think, you know, Semver is obviously the standard, you know, Calver is easily understandable. And I think if we have people that are sort of looking at stuff and they see like a Calver, you know, numbering scheme, you know, I don't think that's something that people are going to struggle with. I would probably push back against, you know, sort of, you know, a more general proposal. We've had fun in the chat defining arbitrarily adversarial numbering systems. But if we said something like, you know, in addition to Semver, you know, people can use Calver, you know, I don't see, I don't know that that would, you know, massively confuse our user base. All right, thank you. So I'm hearing pretty loud and clear, you know, agreement towards not allowing, not opening it all up completely. There's some reluctance to moving towards Calver, but there seems to be a majority in favor of it though. And so I just wanted to ask, so I think we can discard the draft PR that I'll put together and go back to the actual proposal that's on the Wiki that Ray is displaying right now. And my only question is, so do we need to say more about how Calver is used and the potential impact like Angela was talking about? Or do we leave that to the projects? I think you have to leave that to the projects, right? Because like for Ursa, well, I guess it would depend. But for like Ursa, for example, right, why would it care? Somebody who consumes Ursa will care if Ursa introduces a change or whatever and has to put it in their release notes or whatever, but Ursa doesn't really, you know, I mean, not everything's a blockchain, right? No, but I guess I know, but I was thinking maybe along with the, you know, allowing Calver, we could have wording. I don't know if it's in there. Daniel, something about, you know, being clear in the communication of what breaks backward compatibility since it's no longer part of the versioning. Oh, get it back. Can I say something? Get it back here. I'm not sure if I got to what you said because if Ursa changes the signature scheme and signatures that before were considered valid are not valid anymore, this can cause a problem if you upgrade your fabric network to the new, this new version of this signature algorithm. And then you might start saying, oh, what's happening here? Now certain nodes might reject, certain nodes might accept. So that's- What was it applicable to fabric but not to Ursa? Ursa can do whatever it wants. If Ursa screws around, bust something, changes something, does something bad, and it screws with fabric, then fabric either says, Ursa, go change it if we were using it, for example, we're not even using it, or we go find something else. The same thing- No, no, no, no. The same thing- No, no, no, no. Go TLS in 1.15, right? Yeah, yeah, yeah, yeah. I mean, there is an info. For Ursa itself, I agree. We don't care. So who is using Ursa? Should be care very much about what's happening, because as more change can produce a fork. I just think we're putting way more into release numbers than actually matters from a degree. I think everything should have a policy, and anybody who doesn't read release notes on enterprise, commercial, and especially open source software, if they have release notes, doesn't know what they're doing. I agree with this. The problem is another. It's the compatibility. That's not the version. I agree with that. Yeah, but okay. But so I think this is, I agree with Gary in the sense that there's a certain amount of that that's going to be project dependent, and we don't have to get into this as far as the policy is concerned. So I would advise people to look at a rise screen. The formal proposal, I'm leaning towards putting it for Molly and for vote. And the question to me is going to be like, along the lines of using Calvary, it sets a set of criteria that needs to be met for projects that would opt in to use Calvary. And are those the right criteria? Dan, I'm sorry, I saw you raised your hand. Did I take care of? No, you said what I wanted to say. We were starting to get into the minutia that Rai was warning us against. And I think we're ready to take a look at the actual text, which is I think the first four bullets of the proposal there. Yeah, okay, cool, thanks. So if people have a problem with one of those bullets, or if some additional bullets are needed, I think it would be good to say so. But now we're down to like refining the proposal before we put it to vote. I think Dan had concerns about the first bullet, if it's really necessary. Do we care if it's a library standalone program or does it just matter that the project opts into it? Yeah, I'm inclined towards less is more that we can be unnecessarily prescriptive and then have to come back and edit this, so. Yeah, that's a good point. I would agree with that. Dan, do you want to do the edit or do you want me to do the edit? Yeah, there are suggestions for changes. Yeah, it's better. I might as well do it right. Thank you. That way we can all see what you're doing. Okay, there we go. Freeing me if you was corrupt. I'm so used to that. If we're going to formalize that, should we? The parts before the bullets pull us, projects that opt in should meet these criteria. Since I was kind of vague about it, if we're going to make these criteria, we should probably make the header just reflect that. That I should or I must. Right, have we ever? Must, yeah, good point. So which word needs to change here? Projects that would opt in would need to meet these criteria, Colin, and some to these. Some to these. These need to meet these criteria. Thank you. And you just said we should change would need to by must meet. Must, yeah. I think that applies to the shoulds below as well. I'm looking for the other should, I'm sorry. There's three bullets down below and two of them have shoulds. There you go, right there. Yeah, maybe the last bullet, there must be some period of backward compatibility. So that should be a should. I've got a drop. Well, okay. I was hoping to get the vote in. Yeah. I think a should is reasonable for that one. But you can put should exist at the end instead of again. There should exist some period of backwards compatibility. Yeah. Should exist. There we go. I mean, I imagine like if there was a security problem that breaks by question, but if you don't like want to break the day, then you have a good reason to break it anyway. Okay. Me. Any chance that we could get a vote in before we lose one? I moved to vote. That's what I'm hoping for, right? So we, I heard, was that Dan? Yep. All right. Anybody wants to second that? I can second it. Okay. All right, thank you. I'll do a roll call vote. Angelo. I second. Arno. Yes. Chris, we lost. Dan. Affirmative. Gary. Yes. Hart. Yes. Mark is not here. Nathan. Yes. Swada. Yes. Tracy. Yes. And Troy has his regrets. The matter passes. We still have quorum, right? We lost, Chris. That was still eight. Yep. That's still eight. Okay. Cool. All right. That's it then. It's passed. So then we'll have to, I mean, Dan, can you update your PR to reflect this? And yeah, I'll update the PR and I will push it to the repo for form consideration. Yeah. Very good. Thank you. All right. So it's hereby approved and we have a plan, action plan to update the documentation accordingly. And I think we can close this call on that. Thank you. Good discussion. Thank you very much. And I think we made progress. Yeah. Talk again next week, I suppose. All right. Goodbye, guys.