 Welcome everybody. This is the Hyperledger Technical Steering Committee conference call. Everybody is welcome to attend this call and participate respectfully with the other participants here. We have a few announcements on the agenda that maybe I'll let Rye run through those. Quarterly report that we should have all read by this point and then a more substantive topic on the graduation process along with some other discussion topics there it looks like. So Rye if you wouldn't mind reminding us of the announcements there. Oh please. Thanks so in regards to the announcements the Contributor Summit we're still trying to figure out location dates for August 1st and 2nd. It was recommended that we do the 1st and 2nd instead of the two days before because that's a Sunday Monday and for people traveling it's probably easier for us to do a Thursday Friday so those are the days that we're looking for now. The Global Forum was approved by the Governing Board so we're going to be moving forward in regards to looking for the locations for Q1 for 2020. Also the CFP for member summit is going to go out this week for proposals for in Japan and we're going to be doing the quilt reboot again next week. So let me know if you're wanting to participate in that. So if I may ask about the Contributor Summit I understand you have a location. Do we have a general area like a continent? Oh for the contributors that people were asking that I have something done in conjunction with the member summit in Japan and that's why it's still pending on location right now is because we're talking to some other people about possible free locations. Yeah okay I'm with you. Thank you. You're welcome. Okay thank you. Next item we have is the Explorer and I think we've decided to do these reviews offline and then bring forward any issues that need to be raised into this call. I've reviewed the couple comments around that page. I don't see anything that was requiring further discussion but we can take a minute here if somebody else had some issue to raise with the Hyperlator Explorer quarterly report. Okay not hearing any. Next item is the internship proposal selection results. That's me Dan. Alright. So Min and I have been organizing the internship stuff so far actually Min's been doing most of it I've just been along for the ride to help her out. We put together the list of proposals last week put out a survey monkey called for volunteers who wanted to be part of the survey or sorry the selection committee. There were 15 volunteers. I have received 14 responses on the survey monkey. I have provided you a link there to the results. The problem is is that we have 12 clear winners and then we have five ties for the last three spots so we need to pick three and I have highlighted three here with some couple of asterisks which I recommend based on the other internship projects we have already selected and the reason I highlighted these is the ones that I did not highlight is more important here so the scaling real-world HLF deployments there's actually another one that got selected the Hyperledger let's see here. Sorry there's another internship the number one that got selected that was about simulating Hyperledger blockchains using Mininet which is also a scaling internship so we already have a scaling internship and then the other one the Raspberry Pi in the agent. I just don't know that that is something that directly applies to I don't know the direction of Indy it was a proposal that came in it just doesn't fit well with the other theme of the other internships so anyway I've highlighted three here that I recommend but I'm gonna put it to the TSC to pick three of them if we can't decide in the next couple minutes then I'll do another survey monkey and then we'll have this afternoon to all vote independently or tomorrow but we need to choose three like as soon as possible because we plan on launching the application process on Monday so comments discussion I would propose we accept the three that you you suggested and let's have a discussion on it anyone disagree with that excuse me where is the result I cannot see the page refresh the agenda page and I put a link in there that takes you to the survey monkey results I also posted that in the TSC channel on rocket chat thanks Ray um Dan are you in control of screen share no I am what do you want to see could you put the agenda up like we were doing previously so that they can actually so what I'd normally do is I scroll through the agenda itself so that people can see what it is that he's talking about do you see it yes thank you thanks sorry I'm for dropping this all on you guys at the last minute I probably should send to the list this morning to give you guys a chance to read it ahead of time in the interest of not taking up time here we can take this to the mailing list I propose that to all of you yeah just one of our thought is it seems like the people who are volunteering to mentor I would think that they would have the more informed say of what they're mentoring okay all right so that settles it let's say let's keep going and we'll take this the mailing list but just be advised like keep an eye on it because we have to make a decision tonight basically and tomorrow okay thank you all right into the Roja discussion we've got I don't know actually two or three different facets here one is specifically about whether a Roja should proceed to a first production release and supported by Hyperledger and then the second and third are things that were sort of spawned by that question we've got the the need to to more formalize what that release criteria could or should be in general across the projects and then a question of project life cycle and whether we want to or maybe already do have the capability of moving projects backward as well as forward in that life cycle and whether the position in that life cycle is also one of these formal criteria for for a full production release we have had some good discussion on the mail list and I appreciate people taking the time to get their thoughts organized and put into in the mail on the list I think that gives everybody a better shot at a structured conversation here so my last two cents thrown into that's to kick off some discussion here is I think that when we think about what it means for Hyperledger to announce the release in my mind it's not a purely technical readiness question it's also you know this is a statement that Hyperledger is making about backing the readiness of the project and what should that entail and in my mind that should also entail the the community readiness behind the project and that in general we want all of our projects to be multi stakeholder projects multi vendor projects so that we don't have the issues that are incumbent with single vendor projects so I think you know there's been a lot of posting but I have to say you know I I'm not completely sure what we want to focus on I think we can need to kind of you know separate the different issues we are facing there's obviously the specific case of Fira which has triggered the discussion but out of this you know we several things came up and and it's been difficult for me to follow the thread and try to figure out where to post what I wanted to say because it seems like when was with somebody was trying to start a thread on one specific issue then it would split into something else and and it was a little bit all over the map so I you know I had taken the action to try to to express in writing what I tried to say or started touching on during the call last week but you know Dave posted stuff that I thought was similar to what I had meant and so it wasn't clear how much would be worth doing you know in addition to this and and so I you know in the end I figured okay hopefully when we are on the call we can all get on the same page as to you know at least how we want to approach this problem and I mean when I say this problem in general because as I said there are several issues and I think we first need to agree on the issues and then decide on the process and how you know the order in which we want to to approach them and I hate to make it you know more formal than used to be but I really felt the discussion was a little bit all over the map and I don't think we can make progress in that way hey Arno yes after reading through that long discussion that we had all last week I think it kind of boils down to in my mind anyway one question which is would the TSC prevent a project from releasing a 1.0 if their community was not fully ready in some way like their diversity of contributors was not up to snuff or you know did they not have a some documentation or whatever that's community related right they haven't had a meetup or anything like that would the TSC prevent a 1.0 release if their community wasn't in line so and and even though this and with the assumption that the software has gone through all the technical reviews all of the security reviews it's solid there are pilot projects right that kind of stuff as well considering that would would you still prevent it yeah but I don't think that's even a question for per se because we already had that discussion and it's actually written in the life cycle document where if you look at the definition of the first major release it actually says that you know the expectation is that this comes after a project being active but we might consider cases where you know it is not the case and so we've already discussed this and already anticipated that in some case we may go to a 1.0 release even for a project that is in incubation so I don't know that we want to reopen that yet you know clearly there are people who've expressed the desire to have that you know be more like and forced then then we have agreed to in the past yeah my two cents guys one question so this TSE thing that the diversity will increase if you're all has stays in you know in the not first final release so if you don't approve the first final release and then you ask us to fulfill the requirements to increase the diversity do you think this but by not approving it this will help increase the diversity I'm not sure that's the right question to ask I think you know that's like saying well you have you have to make us 1.0 so we can increase diversity which I don't necessarily agree is the right way to go I'm asking that question because we are talking with the number of companies and you know we heard that they are struggling with their management to assign and those are big companies basically to assign resources to the project that is not mature enough and by TSE saying we want to proceed with version 1.0 the you know the EROHA gets as David said before this recognition that it's technically sound and then those companies will be able to convince their management that they should assign resources and start contributing to the project so that's one part of the coin of course we can maybe hear the other part of the coin from your side I'm all in favor for increasing the amount of people working on projects ideally through different you know different companies and all my question is really you know what do we is this do we expect this to be enterprise any project to be enterprise class software or is it just open source do with it what you want my official recommendation on a rohe is that it's ready for 1.0 technically they have done the CII badge they've got all the pieces into place we've secured we've done a security audit and they have addressed issues and they have met the bar that all of the other projects have met to be 1.0 now the question is about community but you know to address Alice's concern I think you know I think that this software is ready for use and I think it's useful to consider the fact that there are companies that would increase diversity that are waiting on the 1.0 designation right but are they ready to support you know issues that come up now that they go to 1.0 because I agree people won't use something necessarily till you get production release something that we have seen some companies do is they want to be part of that release announcement and so at this point we start to get a little bit more into the marketing committees turf but just as far as helping to influence those companies to become an integrated part of your community being able to participate in the release announcement is something that many of them see advantage in so having those contributions in so that they can be part of that announcement is a way that we can satisfy both both goals here and I see Vipin's got his virtual hand raised Vipin if you have a few thoughts yeah couple one is how do you measure that maybe the thing to do is to go back to the principles which is basically if a company pulls out will the project survive that measure is based on the knowledge of the core components contribution to the core components by the companies the vendors case we see we have two projects that are two and 1.0 which is which is fabric and sort of so we got to go back and see what are the real contribution diversity controversy that will help the project go along let's say fabric for for a you know a thought experiment if IBM pulled out with fabric continue if Intel pulled out with with sawtooth continue so to that to that end I say that we have to you know instead of just talking about diversity and community these are practical things so that the project actually has a life beyond its beyond themselves this measurement has to be done I unfortunately I haven't had the time to narrow down such a measurement my measurement would consist of the core contributors at the time when the company when the project went 1.0 in the core components and also putting in another criteria that is not only the company the vendor but all the people that the vendor are paying and directly or indirectly so the investment by the vendor is that what is propping up the project or not this was the metric I was after because I feel that you know there's a lot of ink spilled on this about unity diversity and so on but the core question is will the project continue I think maturity wise when the projects go towards maturity then there's a chance that the project will continue even if the vendor pulls out in fact if you look at any of the projects you will see contributed diversity to the core components is very limited Ethereum has probably 10 or 15 Bitcoin less than 10 guys you know which are contributing the core components I'm not talking about level 2 and other things or or ops stuff Lena started out that way with 5 or 10 guys so are we chasing after something that is not possible to measure at this point in time and if you use a tool like get DM and get all of the contributors and even you know if you take people who have contributed documentation other scripts and other things they are not going to sustain the project if it really goes into 1.0 has serious difficulties anyway this is my thesis and I don't have the data to prove this but all right thank you vipin Silas I saw your hand next and yeah I think some of what we've said there is kind of interesting like the sort of who is the beneficial owner of contributors but that's perhaps another discussion and so I think there is something slightly problematic about coupling community health which I do think is a good idea to try and represent and it and it does like a bit of fire to try and get genuine maintain the diversity but linking that to to software and project maturity I mean so the ability of a project to carry on is an important thing but if you look at you know no one would say for example SQLite is not mature piece of software but it's overwhelmingly be written by one person by Richard Hib it's clear that these are actually different concepts and in fact I mean in the case of Golang like with the new module system it literally breaks that like the fact that we have to use 1.0 to signal something about community that isn't directly related to the software now they're quite correlated so like in the case of burrow right now for example it's not such a big problem I don't think we're ready for a 1.0 release and nor is our community but it is entirely possible for a group of dedicated call maintainers to you know to have a low bus factor but have a highly mature product and I don't know whether there should be something around you know this is community incubation but you can go 1.0 they are they are of course related you know a very successful project that has a benevolent dictator it's quite likely to get picked up in a way that something that's less mature and has less intrinsic value is less likely to so they're not completely independent but I do think there's something problematic with firmly linking community health with software quality software maturity. Alright thanks Silas Hart. Yeah so I have a couple of comments on this first of all I want to ask what are the specific benefits from going from incubation status to active status because I don't really know of anything off the top of my head other than some some marketing stuff. Secondly I'm very interested in getting a formalization of both the incubation to active even though we already have a document it seems like there's a lot of discussion around this and a 1.0 because well hopefully you know hopefully we will be doing these things in Ursa maybe and not the the near future but you know at some point and it would be nice to have a sort of consistent documentation and guidelines around these and as far as the diversity goes I think this kind of thing is going to be very difficult to measure properly like what if we all just go off and make every commit with a fresh Linux foundation account right. I think if we want to if we want to measure this somehow it's going to be very difficult and it's not really clear what what we should do if we want to have diversity requirements. Okay thank you. Bin? Yeah I have a couple of points and and really play back on Vipin's point earlier is that continue those to an open-source project it's very very dynamic. Today we might have diversity tomorrow we might not so at this point it seemed to me from Iroha point of view from a technical point of view Iroha is a good candidate for for 1.0 I think nobody is arguing about the the technical maturity of the project. From the community because of that we need to consider the dynamic city of the contributors calms and go but there's my second point I think it's more important is that the supporting vendors in this case perhaps only one but we have to look at this vendor significant contribution to this project and also what regions that they might likely to go away and I think it's unlikely that that they would go away. It's the same when I looked at fabric for example you know at at 1.0 level the majority of the code contributors came from IBM from other companies there are a couple of other companies but very insignificant I would say that less than 0.5% of the number of lines of code right the actual line of code so you know but would IBM go away it's very unlikely because IBM built a whole business a whole division on this right so I think we have to look further than that that's just the number of vendors that are currently contributing to a project today because that number might disappear tomorrow the same in the case of Iroha when we bought it it would be from incubator to active status there was more contributors than just one vendor but today it's not right so so I think we have to look into that rather than just the number today versus versus it's yesterday or tomorrow. Thank you yeah I want to get a couple of other comments throwing it out there too but yeah I don't think that we will necessarily be able to get to a fully objective measurement but there's also a difference between having something that you can kind of squint at and say all right well there's there's more than one viewpoint expressed in this community and the opposite that it's just really exclusively a single company participating so Baowa and then we'll get to Nikolai after that and then Mark go ahead Baowa yeah my point is we need to separate the technical quality from the ecosystem quality so you know for open source project it's always more difficult to build a mature ecosystem so as the open source community I'd like to suggest that we keep more friendly to all the contributors and to encourage those guys to contribute more so for the one portal I would suggest we focus mostly on the technical points like the code quality while we can still add more criteria for the the steers like we can measure the diversity or something else from the steers if the project want to become active so yeah that's my point thanks. Thanks Nikolai. Thanks then I'd like to double the points you've been so diversity is a very dynamic thing and it is obvious for us as for maintainers of the work that we see we observe right now positive trends in the activities like rocket chat more people pull our local images questions are asked on stack overflow and more and more people contribute to our documentation however code contributions to the code base where you know always this part where people like from outside we're not contributing a lot so we try to improve this with our diversity plan and some of the actions that were made that were written in the plan are already in effect and see that it gives us positive things like contributors come and help us with some libraries that were stale for example scale library giving that and the thing that diversity is a dynamic dynamic kind of substance thing yeah it would be really nice to separate the term technical maturity and community health and community health can be a dynamically absorbed measure combining several things like number of commits per that period of time from several vendors or I don't know number of people participating in like stack overflow answers and so because it's really hard to say whether it's really hard to say that we are really not diverse because we have diversity of people like with this client libraries and contributions to documentation and many other things but at the same time core code contributions are limited to one group and hopefully this will change because as Arish have just said that we have some letter of intents that are oral hopefully there will be documents with some of the companies and some of the companies that don't cannot make this letter of intent they say that the biggest impediment is that we really need to be a production ready solution if we go back to incubation people will think that there is still some work to be hatched and they still associate you know technical maturity with this status as hard has as hard noticed in I think in list there was a message from heart that people will have a wrong perception of rock as a tool that is not yet production ready so my proposal is to make a decision on the first major release considering its state from a technical point of view and in parallel launch a discussion related to life cycle grooming should we separate the states should we put rock a bet and back in incubation and what an outcome it will it will perform on the community and potential vendors that would contribute or would not contribute to the project that's my message I'm sorry can you actually repeat for me right the were you suggesting that it would be okay to move forward with a one oh and simultaneously regress to incubation that that would not harm your project no it's wrong interpretation I say that in parallel we should launch a discussion related to life cycle grooming and separation of states for community health assessment and technical state of the project because in my opinion incubation right now as a word implies things that can be percepted in the wrong way that the project itself is not technically mature and people like the vendors potential users contributors will think that incubation is something that is linked to a technical state so as now we have this you know well life cycle thing this life cycle states they combine you know both technical and community maturity kind of states and my idea is maybe we should separate them and make it visible so that well let's say first major release is a huge technical achievement but in terms of community we have not not the very not the very best weather in one of the projects however I mean sub-projects or let's call it the core eroho code because with our client libraries things are better than than with the core code however we still need to operate with some metrics and I'm really curious if we are going to operate with any of them okay thank you for that clarification uh mark your virtual arm must be very tired please go ahead can you hear me yep yes um so I was going to say let's just at this point you know we're trying to hold them to a standard that we're trying to define on the fly let's just go figure out you know let's vote on a roe hard based on the quote unquote standards that were in place when they when they applied for this and it looks you know that there's a lot more discussion that the tsc has to have on some of these issues but let's not hold up a roe hard for that you know they're sort of being held against their will and it's not going to help them to hold them up I don't think plus one that so just on a separate note on that Dave what's your take on the dco situation that was my more concrete question for you sorry I was uh muted um okay yeah so I did a dco that last week um I created the unique set of contributors for roe hard worked with michael just on to get soar me to developers moved out of that list because they can be covered by a single sign off for me to as employees um we're down to I think I sent the link out to you guys the spreadsheet I built um I don't want to be right now but I think we're had like 27 separate contributors who had landed change sets that did not sign off so um they were not soar me to employees so that that's a pretty significant number I think there should be some effort to try to track them down um and get them to sign off but if we can't then we'll have to squash commit at least at least up to the point to the most recent change set by someone who we can't find or we'll have to get a or get an exception or whatever maybe rye can comment on that like the remediation of this but I know exactly who has contributed that we should try to find so just to be clear I plus one the approval for one oh subject to the to the dco issue being addressed um the code looks good it looks like uh in Nikolai uh you have more to say yes um go ahead I remember in 2017 we used to have a process um even by CLA hub tool and this tool was used to approve that your code is signed off by you just like for the very first requirement is actually here with us during the call so he can give more details but the thing is only later in early 2018 I recall that our our continuous integration pipeline has been changed and this included this new dco boat and this also imposed the new requirement for minus as the option for sign-offs so my question is uh in hyperledger charter section 13 this said that there is a an approved contribution process by hyperledger governing board and linux foundation and there is a sign-off process that should be defined but I'm not able to find any document or decision where this thought which sign-off process is exactly improved so if there's anyone who can help with this issue and tell us exactly where we uh violated the rule because in my opinion if CLA hub is um compliant with these requirements we have no dco issue at all Nikolai I don't think you guys violated the rules um because I think I don't know for sure but I can go back and and confirm this I think those contributions by people who are not sormitsu employees that didn't do the dash s sign-off um happened prior to the erohawk code base coming into hyperledger but erohawk code base is like from 2016 and I think that the very first commits were made by sormitsu employees so we should have no problem and the rest of that is our contributors like those 26 people you told that are non-conformant with sign-offs it doesn't make any sense to me so can you please revisit the charter and investigate the situation more if needed I can cooperate with silona and with sara and we can find out a solution because right now the situation is not really clear whether we have something that is not conformant with the charter or or or it's conformant hang on we should figure this out Nikolai are you asking whether the whether the squash commit hap you know and the sign-off dco stuff happened after all those 27 people contributed otherwise I mean basically the rule was put in place later than the commits by those 27 people okay that makes sense to me but still we don't want to modify history in terms of individual commits the authors will remain the committers possibly pinch because we need to change the commit in order to add a sign-off it's really crucial not to make any squash because in that case people won't be able to see who modified the code base in the particular file so if there is a modification required we will modify a commit but we will not make a squash commit um decision by the team yeah I I'm a little confused how uh how a squash commit fits the underlying IP issues so I know for your I always interpreted that meaning well whoever does the squash basically takes liability for everything that has happened before right seriously so prior to uh hyperledger uh all projects that came into lf were required come in with a squash commit hyperledger is uh exceptional in that way uh and when years ago when clahub was in effect if I recall and I apologize I don't remember exactly that the text of the clahub that people were signing off on was not it was a modified version of the dco so why was clahub turned off as I recall it was because the dco text that was on clahub was not the dco text that we use that the linux foundation uses so that's the why of that and you can't uh and I think this is good you can't go back and change that text retroactively right because that would change history as to what you have signed off on so that was why as I recall so is it possible that we contacted these developers without the dco and asked for some acknowledge yeah that's what I was proposing yeah can you say that again what are you proposing I mean we like to send email to these contributors without the sign off and ask whether they would like to give some sign off or email again yeah of course if they answer that's the easy way out right and I think some number of them will probably say yeah sure yeah whatever but then we get down to just a few that we have to make exceptions for guys not a huge number well we we need to make that first step to find out right that's why I compiled that spreadsheet we have all the email list the emails they use when contributing to the project that's where we should start that's my recommendation anyway because quite frankly if we had an email from all of these people saying yeah it's fine you know I don't think hero uh necessarily has to go through that excruciating pain of going and changing all the commits as long as we have a reference somewhere that say no it's cover you could even like I don't know check the emails in right yeah code base that's what I was saying to say like yeah something like that I mean oh put a link to the archive or something you in my opinion I guess the need for the sign off is only to avoid the legal risk right if we got the email that shall be okay yeah exactly yeah I agree okay so does the dco apply to specific project by project or is it a global thing in other words if some of these people already have a dco in place with Linux foundation would that apply dco is per commit per commit okay that's that's the problem right so now we have a bunch of commits that aren't they don't have the assertion so now what right and the way they got in there was we didn't have the infrastructure in place or they weren't on hyperledger infrastructure when those commits were made but now you can't make a commit without signing off in any of our projects regardless this does mean rewriting the entire history then from those commits that need to be changed and you instead don't get squashed even if they get sign off added it's going to change the hash not if we can get emails from them okay emails are good okay okay there just has to be some there just has to be some form of dco that's in there whether it's the email or the sign off I mean but but I thought the email from Nikolai is that those commits follow the previous procedure something for the TLA could we get bigger that procedure and say those commits are covered I think we need try to solve this in such detail on this call but can I have an owner from some owner or her team to make sure that we are in a healthy sign off state I'll take it well yeah I'll take it I might ask right for a little help but yeah I've already done most of the work so far would it be out of order to ask for you know a vote of 1.0 readiness you know conditional on the dco sign off so that we have a concrete target for the aroha team and they know that next week or the week after if they can get the dco stuff worked out it's purely mechanical they don't need to come back and have another round of argumentation or is that out of order that could certainly be within order if if the tsc members feel like they've heard all the information that that they need to make a decision I get some quick sign from people if they're ready uncomfortable with that uncomfortable yeah we will solve the dco problem sooner or later so the proposal would be that we accept aroha going to 1.0 based on dco resolution it came a little choppy for me but yeah I'll just restate what I think you said that we will momentarily here take a vote on uh enabling Iroha to make a first major release pursuant to clearing their dco history we're gonna we're gonna we're gonna fix any definitional issues with incubation later are we are we making precedent now well uh yeah I guess one other comment that I was going to make either as now or as part of my vote is that I would be willing to take a degree of freedom let's say with what we choose to do for Iroha here based on their long history with with hyper ledger but if we were to get say a new project from a new company that was entirely and exclusively from that one company it would be very important to me that that they go to the required effort to grow a more diverse basis for that project um let me state that one of the things that I'm working on right now is for us to get all this vocabulary ironed out or clearly between both the tsc and the marketing team and all the different projects so that we can have clear defined metrics as to what is you know vendor diversity what are the community health what does all of that actually look like and once we get those things properly defined then it becomes easier to do the enforcement aspects of it because it becomes more of a automated process versus a discussion um so Silas I'm not too worried about the whole previous precedent if we do create these materials and then have both committees vote on them sounds fine to me then and um yeah I think the code looks good too so I vote for one because we certainly don't want to do this to you Silas or would you go to one point out uh yeah we we need to take a look at some of our early GCO stuff anyway okay so uh quickly then before we move into the vote we'll have one or two further topics for the next time we meet one is clearly on the uh one over lease criteria and uh do we are now have a second separate topic on moving from active to incubation for projects or do you feel like that's uh not an issue so interesting enough the project life cycle talks about possible multiple iteration and so there is a already door open for you know the finger point I mean the the you know moving up and down that uh that route and so I think it's more to do with what I would be interested in defining clear criteria for major release I think you know uh we had fabric Chris sent out what was used that was the sole choice of the maintainers Iroha Nikolai sent an email a few weeks ago where you know he describes some things that he felt were relevant but if you compared the two they are quite different least and I think it would be useful to have a list of criteria that we would expect people to at least address as part of the request to move to a major release and that's independent from whether you know a project is active or in incubation I think the you know my my position on the question at hand is I think if it were today Iroha would not qualify to be in active status based on the current definition and the exit criteria from incubation at the same time I think we would support the first major release on that you know basis on the basis we have in the document that says well sometimes we might accept that even for any project in incubation so irrelevant of whether Iroha still qualifies to be in active status or not I think even if they were in incubation today we might be inclined to say yeah technically the project is you know mature enough to qualify for a one-all release okay thank you so next time then we will focus exclusively on the release criteria question and that should leave us just enough time then today if we can do a roll vote right I don't know if that's you or Solona that would be Solona Solona would you like to take us through a roll vote please you are on need if you are attempting to speak okay well uh sorry about that um so first of all um so I guess Dan is initiating the vote so that means who is going to be the second all second and all four yay hi yes hi hi and um those abstaining and those opposed all right then I guess it so lives forward all right congratulations Iroha team congratulations not that easy congrats useful test hopefully it's all the sweeter for the extra effort I can get a night of sleep okay um as we wrap up here then I think we are off next week let me check me on that why would we be off I feel like there was some events I think quite remember there's no plan to cancel that no we actually have some big topics coming up next week um the biggest one being test nets and the CI CD stuff that Dave Hughesby's been working on I'm also going to be talking I hope at that point I'll have all the information I need to talk about the ambassador reboot because we're doing some technological stuff in the back end to enable that which might help our numbers a little that we were just talking about um so I I hope we're not um if you do need someone else to run it then let let us know so that we can get someone else in place to run it okay well we'll we'll handle the phone process offline then um but as usual the the more that we can organize conversations over the mail list and so forth so the better third will be whether or not we're speaking live next week yeah Dave's already planning on posting some of that information about the test sets in CI CD and for me like I said I'm waiting on a meeting to happen and then I can start posting the stuff about the ambassador's program okay my report's coming together all right well thanks everybody and congratulations again to the you know hot team thanks everybody guys bye