EIPIP Meeting 112

Transcript

[Music] oh [Music] oh

[Music] [Music] n

[Music] are suggested by the community we'll

take a look at uh call for inputs which are open and follow the decisions from the closed one and a few other discussion topic along with eips Insight so starting with the first item on the agenda these are a a list of pull requests which are for edits to be made to final proposals the first one is PR 9226 on EIP repository um this is by myself I think uh in one of the earlier meetings we uh discussed that this proposal is missing the time for time stamp value and we

should add it because this proposal has moved into final um yeah I wonder what editors think I think we have received one approve approval from editor we might need more than one Editor to approve because this is a final proposal Victor if you're speaking we can't hear you I see you are unmuted okay yeah uh Sam do you have any thoughts on that I think yeah I approved it okay

perfect so it should be good there moving on to the next one uh this is for poll request number 9186 it contains a bunch of typographical error of course um here yeah some of the approvals have already been received by the original authors but since uh the proposal is proposal is listed a bunch of eaps we may not have received approval from All General thought process here March them all wait for approval I'll I'll take a look through this one

if it's all just small type of fixes I I'll just merge it sounds good um moving on to the next one which is for update EIP 101 pull request number is 9199 so uh EIP 101 is stagnant basically this p request contains changes to three files out of three two are already stagnant and are core proposals which means they are most likely not to be moved forever like one is 101 which is related to Serenity and the other one is 4863 which is related to Beacon chain push withdrawal now chapella has done we already have pass Serenity upgrade so we

may not be ever pushing it um but there is one more proposal listed here which is in final status 25565 if I remember correctly in the earlier meetings we decided that we may not be moving like updating to any stagnant proposal because that will change the state of stagnancy um but for final proposal definitely would require A's thought here like do we want to mer it or what do we want to do here yeah this is removing the like Preamble and stuff so we're definitely not going to merge this I don't know what this PO request is supposed to be doing but uh yeah we're not going to be merging this it would be nice to just leave a

comment over there and eventually this can be closed moving ahead um I think we have received a couple of updates to eap1 one of them is definitely under draft so we may not discuss it today or if you want to add any um Clarity or any uh information around that Sam you can go ahead and do that but the first one which is already in uh draft status it's your proposal I don't know if you would want to add something to uh just give a high level overview or if any editors have thoughts on this like is there anything that is stopping it from merging uh which was this this is 9151 that's correct

okay um yeah I just missed this comment I think you have made the last uh uh update and after that there is no new comments there so yeah [Music] um yeah I'll I'll take care of this one there's not much to do here for anybody else yeah I I just want to make sure because this is for EIP 1 if any other editor has any object ction or they are fine it would be nice to have their

comment added there because generally for EIP one we try to take uh two editors consent to Mar it it would be nice to have all right u i see PR number 9153 is still is in draft status would you want to discuss that or you want to keep it as is a question for Sam 9151 915 9153 yeah that one's still waiting on a call for input so there's a okay nothing to do there we can talk about it during the call for input section sounds good okay now comes one of the

interesting draft proposal that we have received it is listed under the other topics and the pull request number is 9174 so this is a proposal for onchain upgrade signaling um an author is trying to propose some changes to ethereum main net um however it seems like uh some people think that it may may be on the main net ever and it may not be definitely a decision to be taken by codev but this proposal is waiting to be merged in form of draft I see the comment by Gander Singh earlier and some discussion gajender if he would like to maybe provide some high level overview of it what it is and we can collect thoughts from editors what to do about this proposal yeah uh do we have

the author here I thought author was going to join us unfortunately not I have also invited him I sent him the zoom link I don't know why he's not here okay I think this uh PR talks about introducing an upgrade mechanism through extra data where people will say that okay you know validators would signal that uh they are ready for the next upgrade and then there is the votes would be counted and at some point the clients will that uh it's time to upgrade so this is I think what the pr says but as Sam also mentioned that the mechanism isn't quite chisel fully chiseled out so which I I added as a comment uh but even if uh if for example

the specification detail is added by the author do we want to have it because uh at some point earlier uh when I was doing editing I I I thought that Matt mentioned that uh you know we don't want to have p uh eips that will not end up uh or they are not they are not going to be considered in uh for upgrade in ACD uh uh and uh so so my question is whether this for example this uh PR has a discussion to link uh like all others and in the discussion to whether it

should first gather enough support uh for us to then basically consider and merge it and of course with the getting all the specifications properly documented in the in the EIP um so my opinion on this is that it is a properly formatted EIP uh so it should be assigned a number and merged um but then if it goes on all C devs like you can't really talk about it on all cord devs without an EIP number or at least it's difficult to so if this ever does get brought up on aord devs we want to be able to say hey are we ever going to do e 7848 and then people will say no that's a terrible idea or or

whatever they decide to say maybe they say yes I don't know um but we should still give it a number because as editors I don't think we should be making decisions about the technical viability of something like this is possible to implement so yeah yeah so it is correctly formatted but its specification is not complete for example it does not say uh how the Voting is to be incorporated and uh when the vote is to be decided that okay you know so all these things are that makes yeah that that would be a good reason to hold it up yeah so basically if we so uh if we get that incorporated then probably we can then merge it for sure I guess what

is your take on this m that's sound me I just want to like try to understand this one thing right here neither in favor nor in against of merging it but just for the process point of view I think specification is something that can be uh worked on it while it is in draft or review status I don't see personally I don't see that as a blocker uh in order to be not merged as draft but yeah ultimately it's aest decision just trying to understand uh what we are trying to communicate it to community as an author like what you should be coming

up when you are proposing something as draft I think uh so I what what I with with regard to this particular E I think it's pretty important to know uh what is the how exactly the voting client is going to vote and how exactly they are going to decide that uh the vote is finalized uh so that is that is the only thing with regard to completeness of of the idea and of course you know the details can come in later but but seems like to me that so this should be a part of the EIP I guess s that's basically what I was saying too

I think um you need to be able to judge like at a very high level whether or not the proposal is like feasible um and for that you need to have I don't I haven't read this yet but you need to have a a general idea of how it's going to be implemented and if it's missing some key points then I think it's reasonable to ask the author to fill them in before getting meres draft even if it's just like a to-do that says like uh this is what I'm thinking write it out in full or something like that but just to get the general idea across sounds good to me as well I see a couple of client deaths as well I don't know if you got a chance to take a look at it and neither we have going to make

any decision but if you guys have any high level thoughts or opinion about this proposal feel free to add and yes Victor I think uh uh you unmuted wanted to add something feel free okay in that case U gajender would you mind adding just a comment like what specification and author that author should add here in order to get this proposal more well structured and uh minimum specification that is required for this proposal in order to get it merged I think that would be the next

step I think I added that comment but uh I will sort of re highlight it and say that okay we'll accept this uh EIP once we have uh most of the things in maybe just don't use the word accept I don't want to confuse people that it is going to be accepted on mainnet because you are a client developer as well so maybe we can just merge this as yeah yeah just say merge yeah yeah sounds good yeah perfect thank you um all right um moving on to the next one so uh here I think it was mentioned on Kus Discord that we may want to have a tag that can help EAP process I guess it was

um um started by the thread was started by gajender would you want to provide an overview of it what it is and what you are expecting the bot team to add it for you uh regarding the stet dips uh yes yeah so basically I think what really happens is that uh the eips get marked as sagnet I mean uh basically there is a PR that opens up and sometimes when I do get do get to take a look at it for the eips that are under under review I close the PRS but if something escapes uh and what really

happens is that they get Auto merge at some point so which basically is a problem then theor come back and says that this is in review because it's already considered for example for Petra and uh this for happened on one particular EIP I think Max CB uh EIP so what we should do is we should remove the auto merge from the stagna PRS if we want to merge those stagna PRS we can do a manual trigger by approving them Sam you are on mute um you are still unmuted sorry you

are still on mute might want to do it hello now no yes oh you can hear me now okay weird um now I completely forgot what I was going to say uh oh um isn't the stagnant delay like six months something like that yeah I I don't I'm not sure why this particular PR got merged like the the stagnant PR or no no uh the pr to move from review

to stagnant right but like isn't the so had the file been edited in the past six months uh maybe it has not been edited I guess yeah I mean if it hasn't been edited in 6 months I feel like it can move to State I don't know that's maybe just my opinion basically I think it's just that it's under review and uh I mean it's already for example this particular AIP has already been included in Petra and uh people are working on uh this feature has been implemented and is included and people are no more working on it in the sense that there are no more edits on this particular EIP and they are working

all the features while the pectra fork is getting finalized and then this stagnation happens and there are examples like uh 7709 PR which keeps coming up as well as other loal PRS which keep coming up they are uh sort they are actively uh being considered for the future folks and they are part of active development but there's nothing to change on these eips uh and of course you know these uh so these these this is going to last like you know uh work for example might not happen till 2026 so uh so it's like you know a long time

period where these PRS just keep getting created and I just have to keep closing them uh or they should get created after 6 months of last PR being closed I'm not sure what is the uh mechanism of the pr being created to move them to stagnant and if some PR basically escapes my I I'm not able to close it or an author does not notify me uh then they get Auto merged what I really want is that they shouldn't get Auto merged that is the only thing that I want that uh so if for example we see we can have for example in this particular EIP iip meeting if there are any open PR to move for stagnation we can talk and discuss and merge them unless I know for sure or

some other editor know for sure that uh uh it's not uh it's still going to be under active development and uh uh then basically one can close that PR right away without merging them so so either so uh what I want is that there should be a manual trigger for it and maybe we can if there are any open stagnant PRS uh move to stagnant PRS that are out there for long which somebody has not seen or taken action upon either by merging or by closing the pr uh then basically we can have them listed in IP IP meeting and take a manual action in my mind like when we created

this spot the idea was like uh it should work with less editors intervention and I I think I I heard a proposal or a suggestion right here that um maybe an editor be able to close this St and spots PR so um I think we should not just uh disable the property that it should not get merged rather uh doing that we can perhaps make it in a way that when an editor finds it because you know after sending this no so Puja I I do I'm able to close them whenever I see them but sometimes what really happens is that either author does not notify me or it escapes my eye and then one one

set of sort of PR goes through and then it sort of create pains for everyone Al yeah okay I don't know what are other thoughts here because disabling it for like making a manual I think generally when we gets into stagnant status we receive a bunch of PRS like 20 plus proposals are getting into stagnant in one lot so um it could increase job but definitely can be added in IP AP meeting and taken a look um I don't know who is actively working on it uh Sam is there anyone because I know when Panda PE was there he was looking into this do we have anybody actively looking into this and can be

modified there there's a bot that does the the stagnant and you can configure it in the yaml files um I'm just arguing that I I I think we should just assume that if a proposal hasn't been edited in 6 months it's stagnant and then if the author doesn't want it to be stagnant they can just open a PR to move it back to whatever it used to be like 6 months without an without any edits at all is a really long time but we do have functional eips that are going into this again and again and for example worker related eips U 7709 uh it always you know I think every two weeks or every month it creates a

stagnant move to stagnant uh PR and which I keep on closing and rejecting uh so either if you touch the file it'll reset it for six months yeah I mean touching a file is sort of a pain right so I guess yeah so as an editor it's not that handy for me right so if I'm closing a PR uh which basically is a move to stagnant maybe that should uh make sure that the board doesn't touch that particular EIP for the next 6 months I I think that would still be okay okay I can look into that I'll add it to my

list I see a comment I'm just trying to understand here like if we keep bumping that EIP to Future Fork I don't think it will make any changes to the original file uh of The Proposal so not sure if if it can be helpful in any way so that was a comment about the claim that if you haven't touched it edited in six months that it's a dead EIP there's lots of eips they're ready to go Forks that we go up and try and get them scheduled and they get bumped to Future forks and nothing needs to change about the EIP it's just a Process Management thing and since Forks are on a 12 month schedule you know getting a thing bumped means there might not be any relevant edits for you know 12 18 months and thep is far from dead it's just waiting in line

for its place to go forward yeah I think that is a valid concern here very well uh so just for documentation of notes um maybe Sam if you can take a look at it and we can discuss it either on the Discord Channel or by the next meeting whenever it is like whenever there are any solution for this or you have any thoughts or if any other other editor has any thoughts and proposals in order to change the process of current uh stagnant part would be happy to like Implement that all right uh so maybe maybe what we can do is that the pr that are in review state we don't Auto merge to stagnant

but PR which are in draft stage could could be automous to stagnant well could we add unique tags for CFI for specifically named hard fork and exclude those from the search spot so when they fall out of CFI for a particular hard fork and they don't have a hard Fork name for them then they become eligible um I can certainly look into the options here um I think we're just using like a a pre-made bot to do this so I'll see what it can do cool we'll keep it open and maybe we'll get back on

this in the next meeting but yeah please feel free to add any uh suggestions on the Discord channel so anyone interested from the community if they have some ideas on this bot maybe able to help us with this they can come forward moving on the next item on the agenda is call for inputs I see uh three open and one closed Sam if you would like to take this section and maybe provide high level overview for each one of them sure uh let me just go and find there okay so uh 373 this is uh redefining the meta and info um

categories so um if we merge this CFI uh meta will only be for EIP IP related stuff um and all hard Fork um what are currently metas will be moved to the info category um my argument for doing this is because um like meta is kind of relating to itself would be the like my definition of meta um and that makes this more clear uh and we had talked about this in uh last month's call uh so this is kind of just following up on that uh then the next one we have here

is 374 um so EIP 7675 is a list of retroactively added hard Forks or retro retroactively added um eips so for example uh preventing um accounts with code to send like regular transactions uh as an example of a retroactive EIP um because this list will never come to an end there will probably always be more retroactive eips in the future um I think that this EIP is outside the scope of what we should be doing so I'd like to close this EIP and instead um recommend that these retroactive eips should be included in hard Fork um

descriptions in a separate header um so this is again 374 and I'd appreciate people's comments on it um then 375 and if anybody wants to discuss on the call just interrupt me by the way I don't mind um wait 375 what are you um not sure if that's the correct link Pua um yeah okay so I'll skip that one um and then 367

um yeah so this one is um somebody wanted to link to ISO standards currency list um the standard itself is not available for free the list of currencies is uh we had decided to not allow that link and um yeah that's that's that so Sam it was oh yeah 376 it was sorry my bad oh uh allow links to blockchain comons yeah okay so uh this is another request for an external origin that people want to link to this is a standards group called blockchain Commons they maintain uh a standard on encoding streams of data as QR codes so like instead of one QR code it's like a

video of QR codes that you scan uh to allow for transferring more data uh if we want to allow links to it let like comment on here and if we don't also comment on here um they're also relatively new um they started in 2019 and I think that's my biggest objection to uh allowing links to them and I believe that's all the um calls for inputs yeah just as a reminder uh for 373 and 374 the last uh date the deadline is January 17th and today is already J January 15th so please add your thoughts uh I'm I'm a little bit

unclear uh from the comment uh of one of the editors I think gajender your comment isn't very clear like is it in favor or against what do you want to do it would be nice if you can clarify that I see Sam is already in favor so yeah that would help us finish this close this yeah make any decision on that and any other editors please add your comments uh in next two days in order to decide on call for input all right moving ahead we have a bunch of other discussions and updates from the past meetings okay so um just to provide some context here we are hoping to have some new um people joining ining in the

community to help us with EIP editing EIP reviewing and I'm proposing to have this um an intermediate um position called EIP reviewers so generally speaking EIP editors are helping out with only editorial aspects of it which is great which is good which is needed to in order to guard like uh whether the standards are meeting the basic minimum requirement and template we already have discussed this in this meeting itself uh the proposal here is to maybe add more reviewers reviewers for kind of technical review in in terms of core and ERC proposal especially because there are so many proposals which are especially on ERC category have noticed that they are a standard but there may

not be an implementation of this an active implementation so they are or or maybe just one active implementation uh so it would be nice to have this set of reviewers in addition to EIP editors who can help us like understand if the codes are nice and valid and things like that so I have added a link to a document right there um it it is just a proposal uh here the idea is like reviewers would be on a high level reviewers would be looking into the proposals added as a draft or any new pull request which is coming up and trying to add their feedback it can be editorial it can be technical but they can add their

feedback this would help EIP editors to review it fast and if they can simply add okay fine this PLL request is ready to be merged then editor may be able to merge so they may have almost um equal permissions except for two things uh that they would not be able to provide the number and they would not be able to force merge other than that whatever editors do they can also do and I find it it would be very valuable in order to get uh write proposals to be added as a standard like in the meeting today itself we discussed about a proposal which was not spec ready so this can be filtered out and the basic level before getting it merched would love to hear

thoughts and comments on this on uh on this particular topic so uh we can design the process accordingly and may be able to share it in the workshop which we are planning this month yeah I think it's a a pretty good idea to more formalize this position um I generally uh in favor of having more reviewers participating I think uh having some uh new position would be a good idea uh if there's a way to form the groups that would be even better uh L to hear other editors thoughts very well

um it sounds like uh most of the editors are are in favor I have shared the link to the document if you guys have any thoughts feedback comment please try to add it there and we can obviously um keep it improved and we will share it with the community on the workshop that we are planning to have so uh I have added at the end is like kpis to measure success we want to do it as a trial basis so say for example some Reviewer is working on this process and have been engaged with the reviewing process for 6 month or one year then he can be promoted to EIP editor and that would be a good addition to the existing editors that we are having so it can be considered as an intermediate uh position and maybe a future editor so we'll discuss more and feel free to add

your thoughts here um next is new editors checklist um um in the last meeting we discussed a couple of things there were some tips by Sam Wilson There were some highight level onboarding checklist from my end I I think we decided to have these things documented part in EIP 1 and part in EIP 5069 I guess I'm not sure if there are any open pull requests sorry from my end I have not made any pull request to update these proposals if anybody else has made any pull request or has any additional comment on these topics please let us know

if not then we can perhaps revisit when respective poll requests are there and then we'll discuss whether to merge or not moving on the next one is EIP editors Workshop we are planning this workshop on January 17th I have added the link to the agenda here the meeting will be organized at 1600 UTC I'm hoping to have a high level overview of the current process then Sam Wilson will be sharing um a demonstration of editing of a proposal like he always does it in editing office hour but that would be just a walk through right in presence of interested participant so they can ask their questions right then and there

yeah it's a Friday is that okay Sam or do you think it would oh yeah yeah I'm just saying it's like it's not next week it's this Friday if anybody wants to come perfect yeah and I'm I'm in conversation with other editors to have more editing office hour right now we do have two editing office hours in a month but I'm hoping to have more active um office hours and maybe something dedicated to eips only right now in our current office hours we receive a bunch of ERC which Sam is definitely helping us clear it out uh but there are certain uh questions coming up from the core side of the proposals so we can also have dedicated office hours for core proposals discussion review or maybe for

uh new developers to understand how they can document their proposal even better so that's on that wait for the announcement which is upcoming this Friday moving on to the next section we have eips insight for monthly status reporting I see viven on the call I think you have mentioned you want to demo some tool please take it away from here yeah thank you P so uh upon the request in the last C IP meeting we have created new tool for assisting of uh creating EIP template process and uh I have also shared the link in case if you want to visit so uh this will take the

inputs from the user one by one and you can also be uh seeing the expected output on the right side along with the preview of that so uh let me show uh you can see the output over here and uh the reason why this tool can be considered as important is it can be uh quite helpful when a new e uh new person who wants to create a EIP template

uh will be using this so we we have also added these instructions about what to add and the structuring of that like for author we can see the clear structuring of that so that uh they won't be inputting wrong details and also we have added some basic checks for ensuring that the data is correct and uh is in the expected format for example currently U I have filled out the data uh for EIP 76 and once I have completed filling this I'll click on validate in order to validate and if it is successful then it will be showing a message like this and

after that we can download it oh that's really cool so um are you using ew to do that uh no actually U for ew um like we thought of integrating that but there are some things uh like it was throwing an error for the request field when we are inputting it like this it was throwing a error for that and like weird yeah uh that's the reason we excluded that but but we added a basic checks of our own for example current currently these all these viip numbers are existing ones let's say I'm changing the IP number 77020 this is non

non-existent so I'll click on validate now and and it will be throwing an error as an invalid reference so that it will ensure that only the valid eips will be U specified in that and let's say I'm am entering a wrong format for date and I'll click on validate and it will be throwing the erors like check your data for this field and this field like that and uh so this is how it actually works and you can also have the code expected code is over here and the preview of that uh over here and the output file that I just

generated so this is how it looks like I have added some basic data and this is how it looks like for the draft and uh similarly you can build separately for esis and RPS template and the way it will be assistant is for example uh let's say uh currently all the EIP numbers are like this right so when we are creating it for rips uh link should be mentioned in a different way like this so it will automatically convert all those links so uh it will be quite helpful for everyone

in order to do that it it will be similar fors and RP as well so uh this is the tool that we developed and you can visit it over here in tool section for proposal Builder or is this link and uh the other updates that we have made one is for if I may interrupt you here for a minute I have a question one so the ew bot that we have currently that has a special feature especially for the required section that it would not allow a proposal to be listed unless their status is like cleared so for example if someone is

trying to add a proposal which is in uh let's say draft status they cannot be used for uh another proposal in um um higher yeah yeah so right now that's disabled because of the repository split um so we don't have that check right now anyways okay okay in that case then here I think just validating the number is good enough because this tool is hoping to provide drafts only like anybody creating time draft only so here it is only for draft excent thank you yeah uh and like you

can split it based on the like if you want to only edit the data you can use over here like we have added these options in order to make it more easier for you okay one more question I have here with respect to adding EIP or ERC number in respective uh document so for example if an ERC has to refer to an EIP uh how that can be taken care of like how yeah about that uh I have a question actually so this is for the documentation for ERC 107 and this is how it is specified for EIP

20 or EIP 191 which is mentioned over here is this the correct no so it should be ERC but because it's like from 2018 we don't really update it until somebody touches the the file uh like my question was if uh like currently this is for ercs repository and if we want to refer an EIP uh should we be uh linking it like this uh or we have to add a direct link of the GitHub repository along with that uh so all of the links should be uh relative so like sl-20 MD okay yeah okay then

I'll yeah that is [Music] okay we'll update the other ones based on there yeah thank you for that and the second update is for the uh RP proposals and we have added uh this feature for toggling between type and Status so that we can have a clear view of them this is for type and this is for the status and also you can have uh get all the charts and data of all of them in at one place for EIP ERC and RP you can get all the data at one place currently it is showing all this data based on the type

and when you'll toggle to uh sorry based on status and when you'll toggle to type all this data will be changed for the type as well similarly for e and so that uh it everything will be in one place and it can be uh easily accessible and in case if you want to access all the data for all EIP RC and RP at one PR you can go to the all section where everything is combined over here that is on the thing and the third update is regarding the search search part uh and previously we have provided three different tools based on the uh in

this section for author and EIP and uh title and now you can be uh you can access all of them in a single place by using the search by and you can just change this and you can directly use it over here so these are the updates for the website part and coming to the monthly Insight part the changes of this month uh eips and RPS can be visible over here and you can download or visit the individual ones in order to uh check out the data

of them and also so uh for your reference we have also added this feature where you can uh share this link so that we can directly go to this place when you open uh I mean we have modified it so you can share it easily all of them so that's the update from is if there are any questions I'll be happy to answer I have one more question in in the monthly inside part I don't see the name of any rip editors like I'm refering to the uh the document The Meta document of rip it says Anar car Y and Nicholas um just curious like did you not get a hand on the editor list or

because I see uh in draft there is one rip move there would you want to maybe update the tool or yeah yeah we'll update the tool for that thanks for pointing that out okay perfect thank you uh and also I forgot to mention this but we have made PR uh in the eips repository and also shared the link in the agenda uh if any editor will be having a look at that for adding it to. ethereum.org it will be quite helpful for us and it can be accessible for everyone so please consider it yeah thank you

thank you VI I have shared the link to the pr it's 9244 in chat here um editors may be able to add their feedback and if this looks fine uh that can be approved if there are any changes that can be added as comment and we'll bring it up in the next meeting if not if it is not merged by that time yeah [Music] okay all right U moving ahead we have EIP editing office hour I have added the agenda for our 508 editing office hour congratulations to everyone we are reaching to 50th hour of editing office for E editing and that's great there has been a lot of learning

and I hope that this would help and will continue helping the new Authors new developers in the ecosystem to propose their standards people may refer to earlier videos I have added the link to the last one but there is a playlist at e caters YouTube that can can be followed there other than that I'm quickly taking a look at the last meeting notes I think uh it was pending on us to add some uh PR which is not done I will try to get it done before the next meeting other than that it looks all good to me anyone has

any other question comment topic that they would want to add for fure meeting or want to bring it up today here in this meeting very well in that case thank you everyone for joining us here uh I hope the next uh meeting is on um February 19th just for people to know who aren't aware of this new Cadence we try to meet every every 3rd Wednesday of the month at 1500 UTC but I'm hoping to see some of you before February 19th on the call for EIP editors workshop on 17th January

at 1600 UTC So yeah thank you everyone for joining here and have a good rest of the way [Music] [Music]

oh he [Music] oh [Music] [Music]

oh [Music] [Music] oh [Music]