EIPIP Meeting 31

Transcript

welcome to eipip meeting 31 uh this is pujaranjan and the first item on the agenda is splitting out eip reports into eips and ercs there is a link which refer to the issue in which we have some ongoing discussions from past few meetings so in the last meeting we were discussing about how we should focus on the numbering of the eips and ercs there were some suggestions i'm wondering if people have further thought on it because earlier we were planning to uh kind of create some bot or something like that but

it seems that there is another way of customizing the notification so yeah any thoughts oh sorry i was muted can you elaborate on the custom um notifications a little bit is it oh okay you put a screenshot okay i can read this never mind so yeah the my proposal here was like we should keep the process the current process for um eip numbering same for the erc numbering the only difference that i'm proposing here is uh even if we create a separate

repository for ercs the authors of ercs may have to go one additional step to get the erc number and that step would be to create an issue in the current eip repository requesting for erc number and whatever is the issue number will be the erc number for that proposal uh this way we will never have clash uh no new uh process would be needed for numbering eips and ercs and we do not have to uh go back and fix whatever has been done in the past for eips and ercs and for people who are looking for only notification of eips not erc's they can opt out for issues section because

there are options you know we can select what all notification we want okay got it thank you at this point like i'm leaning toward manual like the editors doing it manually unless the bot would be easy enough to do so by manual you mean um uh the process the current process or um yeah so how yeah like how it's done today pretty much and we just do it across both for assigning it um as far as where to start with the

numbering um i've loosened my opinion on that um a little bit to where i might just defer to other people how they want to do it so i don't know what happens um as far as the bot is concerned if it's just like looking at the files um file names on both repos and like making sure that there's no conflicts or anything like that's not very challenging to do um so i'm keeping that in mind i guess i think it's more than just checking for conflicts right because you need to also

check all the pending prs just see if they have a number and sometimes you might have to check if the pr has been assigned by an editor but it hasn't been updated by the author so i think that it's not really going to be possible to automate that by just scraping the the repos i think it has to have like a centralized what's the latest okay incremented by one which again isn't terribly hard it's just you know needs developments work so i think that we could do that in the future but i'm pretty happy with just having a spreadsheet and doing that for a few months

for manual processes i like puja's recommendation of just ercs will grab we'll go over to the eip repo grab a number um editors can do that it's effectively the same as a spreadsheet but it allows the ap process to stay as it is um and it means we don't have to introduce another tool such as a shared spreadsheet like we just have one tool and when it comes the next step of course will be automating and once we do automate then i'm totally down with dropping all that yeah i mean i'm not really opposed to doing that either but i would say like my only hesitation on it is that it doesn't really it's not going to benefit us so much in terms of notifications if people

still have to open issues on the eeps repo for ercs i think it'll be better for sure but it's not you know the full extent whereas i i feel like the spreadsheet is very minimal overhead i guess a couple of more questions that would be you know helpful to decide on this part would be when we are talking about having a separate repository for erc so the number one question will be like um uh who is going to like you know create the erc repo and where it will be all these things and if we can have a

poc for this repository and then everything that it can be maintained where excel sheet that is also a way the proposal i had for issue was a temporary one like till we have the bot or till we have some everything in place so just to start say for example if we want to start from today the erc depository is created and we want to start that is an you know band-aid kind of stuff so yeah for long run but is okay i think so i propose whoever actually goes and gets the erc repo created gets to choose the initial numbering system it's up to opponents after that to uh

make a change to the process after it's been started i really have incentive to move first and to just get things moving um one question i have um how would there never be a conflict between eip and erc numbers through puja's method um i'm trying to figure that part out from the github notification stuff because eip uh issues and pr so they keep on increasing the number even if a person create an issue or a pr number will be changed every time for one repository it's like adding that's a good point you can just turn off uh yeah you could just turn off notifications on the pr's and you said all right issues like you said

yes so you turn off notifications but isn't the pr still numbered starting from one in the new repo okay yes you just don't use yeah you don't use the numbers from the erc repo you only use numbers from the eip repo and so it's like a requirement of creating erc that you go to the east repo and you create an issue as a stub for your heat number oh i think i'm i'm pretty on board with that i think or something something simple and dumb is that i missed it the issues that people

created in the eips repo would just be like a tight one-line title uh erc number request and that's it and then they would immediately be closed like they're literally only there to implement a number and it's not only for reason for existence cool okay if somebody will create the erc repo i will copy the relevant things from the eprepo and start setting it up oh funny thing i just lost my github access because i quit the ethereum foundation so i can't make repos anymore we'll have to find some other one on the inside shoot okay

so yeah no one here has his repo creation access all the admins do and there's only three admins at the ef but i know them all so i can just ask it's not a problem okay cool i think maybe hudson if you can introduce uh them to the editors here like micah and light line would be helpful for future you know because this the number one uh road blocker here is the erc repo and once it is created we can actually like if light client would like to you know add i'll start adding stuff there then eventually we'll start creating process and spreading word around it like what

is the new process and how we would want to do that i can definitely make an intro to the admins uh to micah and like hi just i'll get the eip editors to intro to the admins for the ethereum github that would be very helpful thank you okay so coming back to the question now uh assuming that we we have this erc repo open uh this week or maybe before the next meeting uh we can start transitioning stuff and to begin with are we fine with the proposed method of just creating one line issue on eips yes okay sounds good that that can be a good start

and how do we want to um share this information that's announcing it on the all core dev meeting make sense or do we want some kind of blog or how do we want to let people who are not directly related to core proposals obviously they are preparing an erc so not related to court proposals how how would they get to know about it do ha do we have any thoughts i would say the core dev meeting is the these things micah you cut out for me uh so can you repeat that whole thing again sure sorry about that i would say the all-core devs call is the wrong place because no one like we're taking away the thing that people on that call

presumably don't care about and so telling them we're taking away this thing you don't care about is something they probably also don't care about i would agree with them was that lakeland blind sorry audios can you hear me can't know okay we can hear you now uh so what i'm saying is i hear that there is an all core devs call coming so that would be sorry not all for all devs call no core dabs just all developers can't speak is that the thing trent's

doing yeah so that i mean that would be the perfect place obviously yeah that's true that would be a good place to recruit and stuff yeah but it's you know it's tough because it's not sure when that's happening and you know there are a lot of developers who probably don't go to that stuff anyways so i'm guessing that we try and push out through some public channels and we just have to tell people who open ercs that they have to do on this other repo i mean i don't see an issue publishing a simple blog if people are on board with that idea

on cat hurdles like we did for every other information mostly for the changes that are coming out of this eipip meeting we are happy to do that and maybe then we can start talking about it on public forums yeah it sounds good sounds good to me okay um any more thing on this topic yeah that we all we still have to worry about what to do with eips.ethereum.org because there's the erc tab on that and so it sounds like there's probably going to be some programming need to be do we still want the erc tab to point to the eips over in this new repository

which of course will take some new jekyll programs so we would still have the erc tab in eips.ethereum.org but we just need to find someone to do the additional programming to somehow merge that or something like that but yeah yeah we're working on um we're trying to get that set up and working on our system and we might be able to find some bandwidth to do some development along those lines but i can't guarantee that yet i think that is next question that we would be looking for to be answered but for now um let's start with this github repository

and once that is active and functional and if we see that uh that eips.ethereum.org is not being updated with the new erc's probably then we have to reach out to somebody to fix the bot or however it is added there sounds good yeah we're work like i said we're still working on getting that set up and learning how to deal with all that and i'm trying to get in and learn the programming and stuff like that we might be able to get to a point where we can help with some of that i'm kind of hoping with that but right now i have been able to spend a lot of time on that but what go ahead what bot are you working on um the check if you go to eips.ethereum.org there's um there's a pretty printed

there's a jekyll script that goes out to the repository and makes a pretty printed version of all the eips and you have tabs where you can see all of them the core ones the networking one the erc ones and it displays those in a kind of a pretty printed format and so it's the jekyll script that runs all that is my understanding okay so we should need to update the juggle script at all we just need to remove the erc's from the markdown file oh okay so in other words don't have erc's anywhere in the thing i i thought light client was saying we still want the erc tab but just have the rc tab show the erc's in the new repository oh i was saying the erc tab could just point to the erc's

site editing the template file um and eips repo i don't know exactly where it's at okay anyway yeah we're working on that hopefully i can we can get some resources to help clean some of that up too once we get there sounds good thank you for that um so is there anything else people would like to bring up uh or we can move on to the next one i think i'm gonna paste in uh the zoom chat here um if you brand if you look at that those two lines i think are

the ones you want to edit to make that point somewhere else i believe okay so the next item on the agenda is progress on json rpc api spec in eth1 dot or repository uh recently i i saw some um issues and peers coming from melitta if you have any update on that or you if you would like to talk about it sure um so it's actually still not perfectly clear if i'm gonna be working on that i'm kind of not super experienced so like i don't know i mean

i'm making progress for sure but uh i think tom uh thomas hasn't decided fully yet if i will be um working on that completely but anyways i'm working on eth call right now um and i submitted the eth block number spec and then um so essentially like i i expect to have eth call at least the first iteration of it out um this week and then hopefully things will ramp up from there um because i've been kind of spending the past week like getting acquainted with all the technologies and getting my json rpc um like system setup but anyway

right so i had a word with mass in between and uh between these two meetings and i proposed like having an issue to create a list of what is needed actually and the task and the bounty etc if if that can be done that would be helpful um i think from the tracking purpose uh if if we want to like the cat editors want to uh be involved with this um [Music] specification being added to each one.or spec repo so my proposal is to have that issue created that's number one and a group of reviewers that we would be looking for for kind of reviewing the prs before getting it

merged do people have a specific thought on it like is that a good way to proceed or is there any other better way that can be followed a perfect timing for tomas we just started discussing on json rpc api spec on eat one dot or repo so yeah perfect i'm not sure if alita already gave an update i think it's best if she starts and then maybe i can add some background to it um yeah i gave a a bit of an update on my progress with each call

um and on the block number as well as just kind of referencing the fact that um like it's not super clear if i'll be moving forward with it um yet so i intend on having each call specification ready this week um and then hopefully we'll have a better idea of my involvement in the future from there yeah so the progress we had a few calls with valita and there was like 15 minutes each and we are starting with a block number and then later fell out with if call and if call is a is a very big one so if we have the full spec for if

call and we analyzing there are lots of edge cases so i think i have a few example maybe like 10 maybe 15 and we need to uh find the clarity around them because not not all of them were immediately obvious and then when this if call is finished uh then we make decisions probably on the this this will give us a good estimate of the amount of effort for every of those specifications um because i think i underestimated them a bit before and [Music] and then i i think that was suggested by puja to actually make it a bit more open after that so just post it as the as some kind of uh

git git bounty git coin bounty with the details and and then i guess elita will be already in the place to to be the best uh person to follow up but we also make this part much more open so if other people want to participate uh either as uh as more of people to make it move faster uh or just to like compete for the spot then it might be the way to go but so far i think aletta is doing a a great job uh approaching it very technically and analyzing it in detail so we have lots of setup if i can get running the all the ether is web free and so on and we we see now how much work it is oh thank you for that so i have seen a

few peers there i believe and i have marked uh i don't know micah and you for review do you have any group of reviewers to be marked or how do you plan to you know get notification of that just by activating notification or how do you plan to go about it so my feel is that after friday so elite already opened a special json rpc uh discord channel uh that's been quite active there and i think there's mike there's eric and there are a few other people and then the reviewers should be probably from uh client team developers and uh for now i can give this early feedback i don't want to involve too many people because it's still

a bit rough it would be too early to just use everyone's time but if we cross past this rough time then we send it and all the clients will be approving all the edge cases so we can detect if there is any client work needed to make them in line and consistent and if that's a more demanding quirk or something very simple that can be addressed quickly as for approvers technical approvers for the repository um up to you really to the cut herders to say who who is the one who is merging that in the end i think they can just get the feedback from the client developers not necessarily client developers approving

it to reject yeah merging should not be a problem uh but as for my understanding we may not be technical enough to understand that it is done or not so we the decision could be made based on the comments provided on the pull request that would be super helpful if there is some if something is ready to be merged just a liner mentioning there it is ready and it has been reviewed and something else that that will be helpful that was the plan to do almost something like checkboxes uh for the client developers uh so see if they can comment and mark the checkboxes as this client confirms i don't think they need to participate in the actual formal code review process or maybe like

we'll see after this is finished which one will be more efficient because for code review i'm not sure if you can have external people to do the code review like outside of the repository yeah sounds good so i think i'm good and i have answers to many questions that i was looking for um i'll try to get in touch with lita and you too uh to if if i come across any more questions but do people have anything else that you would want to mention on this topic i think i have one last question that may not be directly related to the

task that we are doing here uh for this um [Music] about the the information sharing uh are we planning to share it with their discord group or mentioning it in the algorithm meeting that people looking for the spec they can visit this repository how do you plan to let community know about this placeholder the new placeholder i think we'll be on the all core devs channel when we have the uh first full specs and anything that is in progress this will be on the on the special channels that delete us set up this should work and i don't think we

need to raise it on the call maybe after a few of those we can once mention it in the all car deaths call to just uh reach out to wider community audience because that's what people may be listening to but i think just the mailing list from the series of oasis calls that we were organizing would be enough to uh to start a bit more cooperation on this sounds good thank you so very much alicante for update on this moving on uh the next item on the agenda is progress on eip github repo action part there is an issue added

in the item itself um so i was wondering on the status of the first set of tasks like i see the last comment um is five days ago so was wondering if it is completed or can be closed or what is the status on it maybe statuses github is annoying [Music] very tedious but we are we're making progress i would say um [Music] almost like the major problems are almost fixed um so i don't know i would say this week it'll be done um depending on micah's

like ability or availability to um review but generally speaking um it's kind of one would look after the next so we're kind of tweaking it as we go so but um we're almost there you can feel it as with all engineering projects um it went far less smoothly than expected yeah with more hack packing than is potentially expected yeah there's just one thing after another that i didn't think about and we originally talked about this like uh things get how cannot do things i should have realized that i can't do but thought it could for some

reason um so hacks and hacks and hacks and it's starting to get close to functional the hats though thankfully are like somewhat dependable i mean they're they are hats um uh they're not terrible they're not i would say it's a lot better than the um the bot that exists right now as far as hacks are concerned um so generally speaking um the final result i strongly believe is going to be much more reliable and much more readable so good to know that so yeah i mean like

from management point of view so i'm always keen to see all the issues getting closed and the work is done because we have to provide status so [Music] as and when you feel that this is done and this can be marked clues um that would be great i hope to see that coming soon do we have anything more on this item yeah just uh continuous shout outs to mike and aleta for doing that yeah i do that i mean yeah this is a

great work uh i have seen the numbers of open pull requests and issue in the eips github repository then and now shout out to elite and mica and like client for closing them all together yeah thanks to micah um for being like responsive at all i really appreciate it i don't know when like what your time zone is but i've been messaging you at like 5 a.m my time so anytime thank you for that no problem i don't sleep so cool uh moving on the next item on the

agenda is progress on canonical source for eips yeah we um we're still working on that we're having troubles getting carving out time to get a lot done but and i think we've already talked about this pretty much we're hoping once we learn the system we'll have some results to show but it's not not much yet so just progress is slow but we are making progress thank you brent uh so now yeah great we are almost on the last item of the agenda that's a review from the previous meeting action items 30.1 split eip and erc 0s

i think we made good progress on that um will will soon see the erc repo and then i think we can start with the process of uh having new erc is in this new repository number two json rpc spec shall be documented under eat one or spec json rpc alita is already working on it thanks so much for providing update number three remove testing green light from eip process um yeah we have updated it uh in the e100 spec repository as well as the ethereum ethereum cathedral's medium blog the new process has been updated

action items a little take on the solutions for minimizing eips and erc numbers overlap i think we are going forward with a different approach for now 30.2 spread the word and find an entry-level resource to contribute to json rbc i'm sure uh we have a plan for that the mass briefly mentioned mentioned about uh bounty and talking about more tasks thirty point three tembico will bring up the agreed changes to eip process in the all core dem meetings unfortunately we did not get chance to mention about it let's see maybe in the next meeting uh we'll try to mention about this uh um

minor change of the process in the upgrade process so that's all that was listed on the agenda today anyone has anything else that they would like to bring up or just as well uh i had one thing in mind i am i'm wanting to bring it up i don't know if this is the right place but again um we we are considering to get eip editors and erc editors funded so i'm i'm curious to know on two parts like commitments and maybe if if there is anything in

anyone's can suggest on what could be the you know dollars per hour or something like that that would be super helpful for us to reach out to um maybe dow or places from where we can get funding it's fine if people don't want to speak on the call but let me know offline as it is yeah estimating for how much something should be worth is difficult but this is a niche skill set so um yeah it'll also depend on how much funding we get to do that um will be but at least if we get a number from

some people i think that would be very helpful to get a number and um have some kind of estimate for at least the average or high end even right so the blog that that was published initially uh where we were kind of trying to list out how how much uh effort would be needed according to that blog it says that zero to five hours per week but i don't know if we are considering for an individual let's say 15 hours per month or something like that but i don't know i'm not one of the editors so having some word from editors would be great here i missed the first part of that sorry i

was disconnected oh i think i think i hear static from pooja i don't know if they're talking but um uh we were asking about any estimate for hourly pay rate for an eip or erc editor so that once we do get funding because we're in the process of looking for funding we can have better estimates oh like what uh what is a reasonable pay to attract the appropriate person for this type of work yeah for a part-time position to start at least oh

that's that's a hard question what country are you hiring from ideally it should it should just be a flat rate regardless of geography that people have the skills sure so the uh in that case you can set a like having hired hired internationally passed what happens is like the rate you set will determine where you get candidates from um if you set a rate that you for example is below what u.s people want then you're going to get candidates from ukraine and philippines and indonesia and india whereas you set a very high rate you get candidates from everywhere um that's why i asked like what kind of

where your target demographic is do you want to attract people from everywhere or you just want to attract people um from like the less expensive locations i think we just want to know data for both so that when we know how much money we get from whoever gives us money for this stuff then we will be able to um apply that and then make decisions based on that right so the tricky part i think is gonna do we want editors who are a who understand the ethereum ecosystem and

like the evms or core dev clients stuff like that or do we just want editors who understand how to write a good standard i think that is likely going to be the big differentiator between the the cost because if you want someone who understands the evm and how ethereum clients work and all those things it's gonna be very expensive because the set of people that know that have a lot of opportunities right now as we all know like you know finding auditors finding core devs finding people to work on ethereum is extremely expensive because they're just so few and so if we're trying to pull pull from that pool of people it's going to be costly they can basically be paying a senior engineer

rate which is you know full-time would be measured in hundreds of thousands of dollars a year um whereas if you're looking for someone who just knows how to do editorial work like making sure that the ip number's there sorry go ahead you cut out for just a second but you i think i think we got what you said so you can keep going okay so the if you're looking for someone who is just doing more editorial work and it's like making sure the formatting is good making sure like the grammar and the spelling is good making sure the wording is okay but they don't necessarily understand the content then that will be you know notably cheaper because you're pulling it pulling from a very different pool of

people but of course you're gonna get very different level of editorial feedback so instead of getting feedback on you know here are some things you can improve content-wise you're just going to get people feedback on hey you know your grammar's wrong here you're scaling wrong here these sections should be rearranged et cetera does that make sense yeah absolutely to add on to that puja or whoever is sort of tracking this is the intent to attract additional eip editors or to pay the ones that are doing existing work so at the moment we have very few active editors so that is one but now we are planning to have an

additional repository erc so mostly we would be looking for erc editors as well right um so the immediate if we say that the requirement would be for erc editor but obviously the present editors we are planning to it cannot be a decent salary as i see it but obviously it's kind of a stipend may not be a good word yeah but yeah i mean like um at least something for the the work that they are doing here obviously this is a very very high high end job and very important for the ethereum chain so yeah

i think it should be both i think to answer your question trent um the current editor should get paid and so should the new ones yeah definitely every everyone everyone should everyone should be paid i just wasn't sure what the intent was like to attract new ones or just pay the ones who are doing existing work i mean who else is doing this besides micah a light client okay well maybe they uh offline they should prepare like what they think would be a fair hourly rate um but i mean i know i think i was gonna say lifeline i know you work

with quilts so like maybe you consider this part of your work already and you wouldn't be submitting hours anyways yeah i mean i think that it's i definitely consider it part of my primary job already and you know a little bit of money is always great but i don't really think that you know receiving funding for me is going to change the amount of time or effort like i put into each repository just because there's a lot of other important projects that i'm trying to help with and this is all this is very important but you know what i'm contributing right now is like usually the max like what i'm able to contribute and i would venture to say that's probably similar for other educators

it's not really an issue of funding it's an issue of time and so you know i definitely think that there is the desire to have some people who maybe aren't don't have as much understanding of the protocol but can't do the editorial tasks and i don't know if that's a different title or like how that specifically works but i also think that could be a development pipeline for people to be more involved in this part of the ecosystem one other thing is maybe we could divide it so that someone who does a full does it full-time and kind of is like the lead makes a little bit more than people who do it part-time but still make but still get funding for that

does anyone have an idea of like what the i etf does because i know they have chairs committee chairs and there are committees involved and the standards and i to me i see that's kind of like you know there's the editorial task which is just you know purely editing uh the standards but there's also this committee task and you know if we just want people editing the standards i don't think that it's important to have like really deep protocol knowledge but in terms of like leading a committee and helping shape proposals but i think maybe that's just different yeah i i agree i think it's it's hard to decide because we need at least one

editor with ebm knowledge so that when there's like a has this reached community consensus and should be merged as final then that can if it's not obvious then that would need to have intervention from an editor not ideally but every once in a while yeah well i mean i think there's a you know a handful of editors you know micah is very active i'm somewhat active alex barrett's aussie is occasionally active so there's definitely people there who can help out in those instances but i think like the work is just you know reviewing things and you know just trying to help out and do those grammar fixes make sure that everything is accounted for

and maybe that's something that you know that doesn't require such a high hourly rate okay i'll think about this personally as well yeah i will too i was gonna say i think it's still like a good way of finding people because to me like the the people who will be doing this job where the funding that really matters is the people who maybe don't have some sort of full-time job already and they are part of the community but maybe they're you know a freelancer open source developer to me i think that this is like a good way to contribute to their funding because again like you know i think i'm just thinking like in terms of myself

and like alex you know we are people who are being funded by consensus in the ef and so it's not again about funding us it's more just like the time and other things that are happening at the moment so while we are here uh discussing this thing uh i mean if there are any recommendation for erc editors to whom we can approach to like talking about these things that we are looking for any anyone if if you guys have any doubt in mind that who could be playing this role

or uh maybe interested in contributing uh i'm just curious maybe i missed the first part of the meeting but what's the need for having a specific erc editor um we are moving towards having a separate repository for eips and ercs and because of time constant or the current eip editors uh they choose to do the eips only and may not give enough time for erc so they're looking for more user data all right are there a lot of erc proposals i guess i see that i'm sorry if i'm coming in without context but it seems

like yes sorry uh yes i think someone said last time about half of all the everything in the aip's repo is zrc's and the ndrcs are definitely the most time-consuming ones too like so given an eip if it's an erc it's going to probably take me two to three times as long to review versus anything else maybe this was just ignorance but is there a reason like is that necessary to review if it's not going into a client um well so i mean that's part of why i decided to drop them is because i was reviewing everything but i don't have time so i had to pick what to drop and ercs are less important than eips

um even just like so when i say review i would review give feedback but ultimately it's up to the author to push through even if i tell them this is a terrible idea i mean i'll merge it if it's um if it's valid but the timezone part is just getting them valid for some reason ercs tend to be incredibly long-winded and wordy compared to eips compared to corey ips core ips very often are like less than a page like it's very terse very to the point whereas ercs can be you know it's like a 50-page document and just getting that like in up to editorial standards it's time consuming ignoring like making it good and useful like just getting it

you know of quali of the quality that we want to have in the eips repo or in the year c3po if we split it out it's a time-consuming process gotcha and answer your question puja i don't have any friends so i don't know anybody um and i hope that you continue to be a part of the cip and ercs so that is even very helpful um okay i mean it seems that there are a few more things that we might want to look into and uh um i don't know maybe on the funding part

i'll try to reach people offline and get some estimate on that i i'm having a thought of you know kind of having one uh as a lightline was suggesting maybe one person with technical knowledge to actually understand what eips and ercs are and look into the um like important uh sections of it and the for grammatical and uh you know spelling mistakes i am not sure like you know uh that uh though for that we should have separate eips or erc editors that that can be a part of it or maybe it can be done on a voluntary basis like people generally seem to create a pull request

suggesting some type of i'm not sure what i'm talking about here right now but uh i think this is something that we should be thinking more through it and maybe we can come up with some some estimate that we can reach out to people for fun for this task uh so actually i just made a friend i would like to recommend hudson as an eip editor oh that sounds great sorry it has to be a minimum one week friendship before you can recommend them oh yeah i have next call i have strict conditions [Laughter] okay thanks so much for running this

page okay thank you everyone um and i see you guys all in two weeks thanks for joining the call today have a good one all right bye bye see you later