All Core Devs - Execution #73

Transcript

[Music] [Music] [Music]

[Music] [Music] [Music] [Applause]

[Music] hello everyone and welcome to today's core developer meeting thank you Tim for running the last one I was away and

thanks for everybody for participating and I hope everyone had a great Devcon who was able to go I had a good time overall I think Japan might be my favorite place to visit so far um let's see oh it's tambul that's a big item and that's the first one we're gonna talk about is there any updates on the Istanbul tests nets that have been launched so far does anyone have anything significant it seems pretty quiet overall yeah I haven't seen anything the issues

either so that means we can probably look for a main net block number now so do we have any ideas on that or are we gonna decide that in get her what what are people thinking and I guess the first thing would be like what's a rough date we want to do it and then we can decide a block number around that yeah so my thinking was we want to target like the fourth or eleventh of December and not do the 18th 25th and 1st of January or the 8th so I think those are the the 4th 11th or 8th of January are

the real targets we should be discussing sorry well one was the first that you're really quiet Martin I believe you said January when you intended to say December in that last can you list the three candidate dates again sorry I said both December 4th December 11th and then January 8th I think are the ones we probably want to target I don't think we want yeah that gives a month right like it was a little over a month for people to get ready for six there's six weeks oh nice um yeah I'm good with December

where was it December Fort Worth we've got the week of December 4th yep and that sounds good to me does anyone else have any ideas or comments on that I would say

Piper Merriam: if we shoot for December 4th and if that gets shot down and we'd potentially push out the four weeks to the January mark so that we're not running up against holiday weeks

just you know but that's that's just my my gut speaking there

Tim Beiko: by shut down do

you mean like if there's an issue found with Istanbul

just some unforeseen thing that causes us to want to push back just a little bit or something and then and then we're coming right up against the the holiday line so I'm just thinking we shoot for the first week of December there and then if that falls back then we go back for weeks I like that to get a fixed fallback day because that sets the standard every gonna stop the shipment is it worth shipping it a month is it what stuff we get a month that's the standard for how critical the issue needs to be is if it's bad enough Nidoqueen a month then we should I like that I like that too any other comments on that otherwise

Hudson Jameson: we'll figure out the block number in the get er chat and just figure that out today let's set a goal for figuring it out today

yeah so that I just have a question of what is the good reason not to do it earlier or

James Hancock: what is the reasoning for not having if you'd be sooner than

that

Danno Ferrin: all the clients need to put the block number into their code and they need to ship the code and then all the exchanges and note operators and you know download that code and install that code so I think for weeks at a minimum is what we should budget for that

sort of process of getting it shipped getting it out there and give me any user clients installed so you're saying this basically gives if we do the fourth we

give two weeks to clients to actually implement the change and then four weeks there for everyone to upgrade yeah I mean clients could do it in an hour it's just getting it through the release process that doesn't take the longer time not

James Hancock: my only worry on that by having the backstop date be at January like pushing Berlin too far back the next one will may get into problems with the the ice age so I would rather have it be four weeks out with a backstop like have the next third Wednesday on the in November see the backs uh but that's

probably Thanksgiving so that doesn't work but having the backstop be the December date so that it isn't pushed in January

for the one hiccup that happens that makes sense yeah

Hudson Jameson: but if we do that then we might not be giving

enough time for exchanges to upgrade so that makes sense yeah there's nothing we can't use second December it's just that if we consents and easy backstops here and we can always change your mind later the situation calls for it so that the backstop date

Danno Ferrin: is there's also the same process if we're gonna

ship and change the time we have to build a new client ship it out and get everyone to install it so that's why I think at least four weeks

for Rhys pin is necessary no argument here on that okay so if you're all good James we'll just do the week of what do we end up saying December 4th 4th and January 8th as a backstop yep that's good ok great that's decided then let's move on to a IP 21:24 I got a Google search that one

that one is oh is that the new Fork identifier yeah that's the one I think Peter did that one yeah Peter and Felix so is it on the agenda to just I I don't I wasn't at the last meeting was it on the agenda just to continue to discuss or so actually the reason why was I wanted to postpone so the idea with the fork idea we published that a long time ago so probably around I don't know March from a and the people in generally said that it's fine and who for kaya big thing is okay and could be

honest we didn't really push it a lot harder because it was mostly just a specification of how this for Chi B would be would look like but it was wasn't actually a specification to include it anywhere general internal people kind of liked the idea and then the reason why we brought it up again is because we had his issues with Roxton where the network essentially there was a miner pushing the non forked chain quite a lot and generally it clients have a hard time following an on majority chain so usually you need to tweak the clients add some white listing flags or black listing flags to make

sure that they are on the correct chain and all of these issues can be fixed by the by actually including the for guiding protocol handshakes essentially this was the reason why the whole fork idea was created and designed and then the question really was the reason why we brought this Yeti up again is because we have an implantation and a proposal to include it in the handshake of the eath protocol essentially just replacing the genesis hash field with this work ID field so it's just a tiny beyond trivial change however since it's an ecosystem change we felt that we owe it to the ecosystem to actually get a thumbs up and not just roll it out in Gath and so

as far as I know people already liked the idea of fork IDs so that's nothing new this this talk is just about whether we whether anyone has any opposition to actually start using it or not be using it but I'm curious about motivation to replacing Genesis hash with it and why not just add it as that

Péter Szilágyi: because the Genesis hash is already hashed into the fourth ID

right

Piper Merriam: but it's opaque which makes it like non inspectable if it isn't what you have which means that you can't like that you lose data there then it isn't a

like

no value you can't actually tell what the other client is yeah but so even now you can't differentiate for example between if you're in classical etherion so so

Piper Merriam: you can differentiate between oh that is Roxton or or something like that I mean I guess you can in theory do that with work ID but if they mix in different block numbers then you've lost

it too so well yeah but why yeah I guess my question is does it make so

Péter Szilágyi: if it is based on the Rob's turn Genesis hash but it worked away into a

completely different direction then it's not really Roxton anymore so does it matter that you don't account it as a Robster note if you know that it's not

drops then I am

Piper Merriam: just starting to think about this but that really the bit is that it if you lose that information it's like an easy classifier for who you're talking to that that's my my only objection since it's four bytes in a one time message it seems simple to to to keep both or to keep Genesis hash and

include for ID at least that would be my default inclination yeah so I guess I'm

not really married to by the way so if anyone else has any opinion but for example one thing that we can do is that in each 60 I don't know three four whatever is the next one we can just add to the fork I didn't as a new field and essentially they would run side by side and then later on if we decide the point of the Genesis hash we can always drop it later [Music] say that makes people feel better I'm fine by the way yeah

Piper Merriam: I have a much easier time saying yes to that

I'm willing to be convinced the other way but but in general thumbs

up to iterating the Eve protocol and adding or hiding the status message so just just to confirm here this is since it's not touching the EVM or anything internal this can go in together by itself it doesn't necessarily have to don't would be nice to have it yeah of course so on so

Péter Szilágyi: this is just a networking thing so if get throws out in 64 with this extension we will still support the old protocol so every client will still be able to talk together like nothing happened so it is fully backward-compatible the reason why it would be nice to have at least the

consensus that this is a good idea is because if is actually the theorem namespace so we don't want to turn it into a

gas wave space all right we also hear from Basu parity and maybe the II was um team and anyone else for their concerns

Danno Ferrin: I like it going in this is basic weather is with the separate field or Genesis I am neutral on but something like this going in I view as a net positive

great parity are you cool with it way great and then Tomas another mind

Tomasz Stańczak: I just joined with us whom it's the discussion on the improvement on the history of Forks in the synchronization mechanism the handshake so I'm totally in favor of this change I've been reviewing it

good great is there anyone else who has comments okay let's just say it's good together than our okay us anyone else has it yeah then I'll make the minor modification that Piper suggested to keep this hash to and I just open up an EIP probably it will be a tiny idea to spec it so that it's official and there's some written thing

yeah it'd be a networking IP which it looks like you and Felix already correctly prescribed to that EIP okay next up we have Birla I just said I had

James Hancock: a meta question about that before I know they don't I know that these kind of changes don't require hard forks is there still valuing or should we have them go through the same the IP centric process or kind of go through that same funnel

if they're going through networking or yes okay so and in a way it'll it kind of did already um sorry I think that

Piper Merriam: that question may have been misunderstood do you mean like actually having coordination and block numbers

is

that what you're you're referring to here

James Hancock: no I mean the proposal that Martin gave that there's an initial greenlight and then there's work done in the testing and then a final approval and an implementation

if

Piper Merriam: I don't think that makes sense since this isn't a consensus issue that this is kind of completely orthogonal from the consensus part you're referring to kind of like the EEP centric four King and the signalling mechanisms right

James Hancock: yeah in general it's the do if the same people are should it go through that same kind of process or should it have its own process

Martin Holst Swende: I would agree with Piper

Piper Merriam: yeah because we have we

have mechanisms in the networking protocol for like negotiating the I'm on version 63 I'm on version 64 I support both that sort of thing this isn't a thing where everybody has to agree on it um so so it's it's fine for any client to roll it out today if they wanted to and it wouldn't affect the network

or other other Peters really yeah what

Alex Beregszaszi: question regarding the CI piece because we do have an networking category and 21:24 is there and a couple of other no discovery VIPs or ERC's whatever you might call them they are in draft status

right now and I think one of the questions maybe James had whether we should have a I piece for for all of these and I would have a question whether we should move them to final if they are adopted

so I would say that yes we should have a I t's because the idea is act as these documentation so that you have essentially two spec so that if you look at you wondering what each 64 is you can just pull up the spec and then you immediately see what the difference compared to previous ones so if not for other even for documentation I think it's worthwhile to have a nice

back of the of the change as for draft versus final I think yes if we agree that we want to roll it out then when we roll it out you should probably mark for example the fork ID I think there's some minor corner cases that somebody suggested we can do cleaner but otherwise it's kind of more or less final in my opinion however the discovery ones I don't know so that can be played around with I'm not sure how final that is probably Felix is a better person to ask so there are quite a few EITS which are kind of independent from one another so

this for fork ID thing is completely independent of the discovery in the IDs okay I think then hmm I think we need to

Hudson Jameson: we need to fix some of the EIP process so this is more clear but just to avoid doing process for the sake of process and slowing down in the implementation I think we can say this is final and

agreed-upon and then we'll need to work on how to better provide a process for these in the future and I think that's kind of where you get that James right yeah I would I would

agree with that and we can we can move on from that

James Hancock: I'm just trying to suss out what are things that should go through that funnel and what are things that don't and what we should do about the EIP process in general and moving forward on how to improve the whole system

so just to add a slide to die diverge from that slightly I think so one of the whole reasons why this whole networking changes and especially fixes work around discovery is a bit problematic in the IP process itself it's because it's quite a few steps for example there's an EIP on the LRC IP on extending discovery v4 with the NRS there's an exe for discovering v5 there's an eID for fork ideas setter

etcetera and honestly these all should be individually IPs because they are completely independently scoped tiny sub modules or some protocol things however the problem is that most people don't care about that working at all or a lot of teams don't have the capacity to work on networking or they don't care or they don't have whatever and other thing is that as far as I see it currently mostly Felix and Frank is the two people who push that working aspect but the only way to prove that these fact that these things like en ours and discovery

protocols and the new DNS discovery the only way to prove that they are useful is to actually more or less spec them out implement them roll them out and then start demonstrating that hey these work so we can't really get stuck and block each individual a IP and have discussions because most people don't care most people want to see that yes it actually works the whole system the whole dream actually works and only then wait will they actually invest the effort which i think is fine but this makes it a bit weird in the active process

Hudson Jameson: that's good to know we should correct the IP process to take that into

account

any other comments well as you said Peter the

Alex Beregszaszi: minimum it would be nice to to have a final documentation of each of these networking features or changes and it seems like the EIP repo may be a good place to have them

yeah

Péter Szilágyi: and I will open a new one for the

864 proposal okay moving on to Berlin so this one is going to be a fork that is post Istanbul

we need to talk about a few different things here what's listed is the process and scheduling discussions the Ice Age and the tentatively accepted e ip's I think we should talk about tentatively accepted the IPS at the end and I'm debating whether to talk about the Ice Age or the process and scheduling first because I think Ice Ages dependent or one is dependent on the other I'm trying to figure out which way should they be dependent on the other and I guess it depends on when the ice age is supposed to happen does anyone have an estimate for that well if we go down with the EIP centric thing and the ice age can be just another Yankee centric thing they'll get soft there so I agree that's like VIP centric process

it's probably

Tim Beiko: something you want to aim towards I think that given like historically how slow hard Forks have been going from like year long hard Forks with a bunch of eats to month like months in between hard Forex and like one eat for hard for it might be too much too soon and so I I was wondering if there's maybe like a middle ground we can do here like have an upgrade that's you know just commit they're upgrading and say six months with whatever is actually ready then so kind of using the EIP process proposed by martin but not necessarily going live with each eat just agreeing on a date shipping whatever is ready by that point and

having that be much quicker than our current 1 year cycle but without going all the way to just having one upgrade

for eat yeah yeah so I don't think we necessarily want to go with one upgrade EEP so I think it's completely fine to say that there so even the EIP centric approach we could say that the AIE X is ready but we know that there are two more EITS that are almost ready and can be done in two weeks so it makes sense to bundle them together so we don't necessarily have to do cowboy style let's soon as it's ready shoot it's it's live but we try to do the half year or I think it was eight month hard Forks originally so Istanbul I think even

Constantinople was supposed to be an eight month thing and at least our results where that yeah can we just add this one and that one and that one because people kind of always feel that if they miss the heart for them god knows when the next one will be so sorry on that last point of like if people missed a heart Fork I think this is kind of why moving saying we'll have lost like a hard fork in six months and maybe pre committing that there will be another one six months after - that kind of just provides this visibility for the community that these things are gonna happen on a regular schedule yeah so that's that's just my when I far as

James Hancock: looking backwards on the state of the fork process and how things have been slower than we had wanted to my view is the reason is because it hasn't been any IP centric and that the solution is the scheduling will be a lot easier when we're working with things that are ready to be shipped

I think the babies taking up a centric approach in favor of the IP centric approach as Peter says maybe sometimes there is one interesting consequence of this if there is any IP

that will be particularly on dividing then wonnie I people really gives potential it's theoretically community more of the possibility to to reject it yeah that's a fair point and I kind of I would say that that might be actually a drawback we can't see the problem subject as well it's sometimes bit easier to push importance changes with the community if they are bundled but I'm not that's really sure if this is fair however it may it may lead to

situations where people try to suggest that it's a hybrid process for this like considering EAP central anything really or 10th floor and we are continuing the I have pasted the link here and you guys who have a look around it I mean basically what I'm trying to say here is we can ton get for a biannual of credit but there should not be any fixed month it would depend upon the readiness

of EITS and we can consider say for example 3 IPS that are bringing substantial changes we can bundle them together and then we should come come to the scheduled path when a IPS are ready we should be I mean the hypokinetic may be providing the timeline when we would be getting into implementation tests not the it may not upgrade and these thing can be time bound but not the fixing date that in this month we have to get into an upgrade that's my suggestion hmm yeah that sounds like a yeah that's like a time bound plus EIP bound okay yeah

kind of hybrid model abort so I think one of things worth pointing out that's different from what this proposed normal is tests are supposed to come before we include it in a block because what we did before as we would decide what was in the fork and then Alec would have to implement it and then we have the records tests so now that retest us is out and we can write our tests invasive gear yeah or or alle you know we could test before we ship and I think that was one of the things that don't back previous releases of the tests took longer to write than anticipated

Hudson Jameson: so an order of things that are important

I think that would be near the top is making a upgrade model that puts tests first meaning nothing has even approved until tests are made is that is that something most of us can agree on

though I'd like to so I

Piper Merriam: I like the discussion on process but I also really like trying this sort of fundamentally different approach of the IP subject working on this very easy candidates fork which can which may only include a change to the ice age which is very simple and

uncontroversial sort of like trying centric working with our training wheels on so I'd like to advocate that we try this this one time it isn't necessarily what we're committing to for the future once we've done it we can talk about it and we'll see how it went

and continue to discuss all of these potential hybrid approaches potential problems that might come things like that but maybe it's good for us to try try doing it this sort of fundamentally different way once just to see how it goes yeah and I just want to us that's the comment at Hudson

about test first so the thing is

Martin Holst Swende: why testing drags its feet quite a lot historically is that it's very difficult to do the testing and produce the test cases where there are no clients that I've been demented so therefore the implementation needs to come pretty soon and be

activatable in the clients clients oh yeah I I agree with that I think I was more meaning we don't like we've been doing before we don't say we want to do this eh I pee and then we go through all of the steps only two at the end of it say oh we don't want to do it anymore

because we found this during implementation I guess it's like do final approval after everything's done I guess is what I was trying to say it's hard to word yeah okay so I'm liking Piper's idea and the reason is we couldn't right now that for the train model which is the one that Tim and Dano suggested with the two two forks a year on a specific date like the third Wednesday of whatever date we or month we choose that process I like that but I don't think we can try that until after Berlin because of the ice age so we wouldn't be able to say like it wouldn't

be to a year it would be like it would feel like it need to be three that year or something like that like it just doesn't feel like we can do that model with Berlin what do you all think Tim and Danna is that something that's accurate or how would you fit Berlin into your model

Tim Beiko: I think the counter-argument is aside from the ice age which I think on the last call we said was not until next summer so it's something that's not super urgent the two Apes that had sort of the most traction for Berlin were 1962 and Prague

pal profiles obviously pretty controversial and Martin this morning put a pretty long comment around 1962 so that one also has some stuff to figure out all this to say I think we actually there's actually case if he made that maybe we don't have that many heaps ready for burden anyways and if that's the case and maybe just having an open upgrade and having that be six months in the future

also makes sense that's I think where strong opinion I would think along the lines of Piper and part of me worries that work we're pre optimizing for sort of a little bit of the not looking at it I

pre optimizing for stuff and assuming a lot of things we don't know all right I would one thing that'll be different with like moving forward is one I'm I'm joining the you have to help with hard for coordination so we'll have a lot more time and I on the process itself and something I want to push forward and as far as the EIP centric model goes for me it's a focus on getting me eyepiece ready rather than focus on when are we going to release whatever and then figure out what will fit so just the the it's saying we're going to have two forks per year wouldn't be the way that I would I would say let's have like a

schedule and windows that are available that people know in advance so that people can prepare for it and then work on how many upgrades we're gonna get in this year I think I followed almost all of that except at the very end so can you do like a summary of what you said at the very end yeah the changing the attitude from oh how many Forks are we going to have this year to focusing on getting a IPS progressing through the epicenters model and then scheduling them when they're ready and having a system of that okay like a way of setting the schedule so it's consistent predictable for people

to use I'm using the third Wednesday about having the windows being six windows a year that it can ship rather than but not saying we're going to fort something then or ship something then we can if there is something ready this is when they will go through and if it if it if it doesn't make that two-month window then it hits the next one and it doesn't hit the next one and it still keeps the focus on getting a IPs ready to be forward rather than saying hey let's have this date and this white focusing on when getting Forks are getting out okay I think that's

Hudson Jameson: I think that's good as far as what we're gonna do for Berlin it sounds like things are

tending toward more of an EIP centric model for the e IPS that are done which would be the Ice Age like the ice age block one is so easy it would be a really great practice because we can say this has gone through the process of the EIP being written you know being implemented the test case is going in which I don't even know if we even do test cases for that or if we do it's just like a couple and and then finally saying it's going in and then scheduling it with any other AI peas that are done around it if not we'll just do a single hard fork for the ice age

oh by the way

Martin Holst Swende: volunteer to write a need for the ice age postponement

yeah

James Hancock: I can

do that

cool thank you okay yeah I think last year we didn't do that and then operate it at the last minute I was wondering when to interrupt this

Alex Beregszaszi: this might be maybe an unpopular opinion but I kind of feel like that the EIP centric model is actually what we have been trying to do with one exception but these steps and the IP centric model explains it's pretty much the same what we have in the IP one however somehow we were not successful at enforcing those

steps and so in the EIP one they initially accepted is just called accepted which basically means that people are they're happy with the idea but then it would be down to the VIP champion or proposer to do all the steps implementation thinking things in the IP one just we never enforce them and I wonder how will we enforce this and I see a couple of problems we have been in the past number one is had to get people to review a IPs first of all and give the

opinion in Istanbul one example was the Blake - it took quite a bit until some people from clients could actually focus on giving feedback on the IP actual low level feedback because most of these low-level yuppies especially the ones affecting the EVM it's fine if you give a blessing that you know in essence the IP looks good and then ask the or let the champions to implement them create the test cases but then how many cycles do you do would you accept of reviews and changes to that and if you don't

want this to be a never-ending process then you need to somehow motivate people likely from this group to give those reviews prior to the first like blessing

state do this so

Piper Merriam: I have some thoughts on this I'm not necessarily like ready to share in detail but what I'm interested in us looking into is pursuing the kind of research model that at least my team has going on - with having dedicated resources on the client teams that are focused less on client maintenance and

development and more on upcoming research and implementation trying those things out and in that model you've got people who more vested in participating in discussions about eats in generating test cases because they're collaborating with similar other teams who are focusing on these same things and and I think it fixes some of the motivation and attention problems that we've continuously based for the entirety of the history of network

I'm so actually

Alex Beregszaszi: Piper my second question ties into to what you said that there have been a couple of IPs which had been well

received but it turned out that the champions were never really considered to implement those changes themselves or create the test cases they were only interested in giving the idea sharing the idea and then expecting client developers to finish it off I wonder what will happen with those we just we just took up the the work in the past you know how this work in the future

so

Hudson Jameson: to answer both your questions the first one is how are we gonna be motivated excuse me how are we gonna be motivated to continue to to basically the fact that we were trying to do in the IP

centric model sort of before and I think the difference between Constantinople and a stamp and what is Istanbul now and even the ones before Constantinople which was what was it called it's bothering me now what was the fork before Constance no more Byzantium yeah yeah so the reason is because now we have more resources that are in the hybrid technical non-technical range so James just got hired to specifically like have their eyes on the process work with people to improve the process and

formalize it and make and talk to the client teams and make sure everything's being done properly also have people like Pooja Tim and Trent and other people who've been attending the calls Brent - who are behind the scenes helping with stuff more so and they've come on the scene in the last six to eight months and have been growing in their roles and their unofficial roles I guess I should say so that's gonna be the primary determining factor for you saying how's it gonna be different than what we were trying before I think we have more people power now and we have like it's like that's gonna make a huge difference I think and then for your second question that was how are we going to incentivize people

to look at the e ip's more closely I personally like Alexie's working group model where you basically when you have any IP you have a champion and they're responsible for everything and then you also have actually let me just put the link in what the process could be so yeah you have improvement proposals that aren't formal you have working groups around them and then those working groups improve like work with the client teams and on both we're reviewing and implementation and testing and those working groups of the people who have vested interest basically recruit and push for things like review and

implementation oppai pushed it in the wrong chat here we are so if you look at the what the process could be a theory m1x it has a bunch of charts on with smiley faces on what the process could be like in the future and I think we don't need to figure it out today but be kind of thinking about this model with the other ones we've talked about when considering how we can change things for the future

Alex Beregszaszi: um I just wanted to drop one last concern share instead so basically if we I mean there's no way to scale the work

as it is right now because it's mostly client developers who who try to do everything and most of these proposals would would mean that we would separate these concerns and try to engage more people in the work itself and in that model the client developers likely did they role would be to give this initial review and then reviews to other process but they wouldn't be required to implement all of these changes themselves however a lot of VIPs are proposed by client developers themselves because they're close to their the

network and they see issues and they want to fix those issues so will is a is there a potential that we're going to get into a situation where these client developers gonna propose the unit yet is going to only work on the only IPs and everything else gets neglected

Piper Merriam: I don't think so but I'm not sure which model we're talking about in the concept that I'm sort of working towards right now it involves a lot more close collaboration between client developers so that we're not all working on the our own solutions to the same problems at the same time so that we collaborate more closely and work on similar things more closely

concurrently okay let's see Trent said something trend did you want to say something oh you're muted if you're saying anything trying maybe maybe the mic isn't working and that's why oh okay I'll just read the comment

Hudson Jameson: what does the gift team look like are there efforts to onboard more core members to that team what would help shepherding a IPS and the same can be asked of parity and

neither mind and the other clients Bessie is there is there any ways that we can expressly try to recruit more people to the core team or would that would that help Shepherd

e IPS whatever people's opinions yes so speaking for the gas from the getting's perspective we've probably

Péter Szilágyi: been doing a really crappy job at trying to find new people however back when we did have a few people join and then leave generally it's not easy to find somebody who would be enthusiastic about working on low level protocols that wasn't kind of our

the things that I we've learned that the gas code base is quite complex it's quite a lot of optimization so we there is a pretty steep learning curve to just jump in and start making modifications and it's also really hard to review and approve be ours for example specifically because there's quite a lot at risk and it's a bit critical so it's it's kind of hard to find people and as far as I see it not many people enjoy spending a month trying to get a 25% speed improvement in some weird corner case of of the GAF codebase so I I would be really happy to get somebody on board

but it's I it's not it has not been easy in the past

to do such a thing I'll kind of echo what Peter said like so I'm from base you Pegasus we are actively hiring the engineers so if there's anyone with a Java background who's interested in this stuff and the protocol generally we are hiring and the the the I think it's finding like the intersection of people who have like the technical experience desired to do this and also there's a lot there's a fair bit of like non-technical work that goes into shepherding if so there's like the uncertainty around you know what if you work on this thing for a year it actually doesn't make it in so it is

hard to find people but I think if you reach out to anyone on this call your destiny and you're interested we can probably find you somewhere where you can help the community and there's probably client being written in your favorite language so here's you know people in sure be interested in talking any other comments on these processes and I think what we need to somehow solve is this step one getting the the blessing from a medicine from the IP centric document but basically the the

point where we we weren't really good at in the past is reviewing a IPs giving initial feedback and I'm not sure what's the best solution but I think it would be nice if if there would be like your recurring way maybe every two weeks to query ip's have to be looked at by people attending or kordell's likely not on the call but you know outside of the call but I just wonder if there's there's no like scheduled way to look at a IPS and have how will people get any

kind of blessing of the IPS because in the past this has been it has been that there was no process where people just kept coming back and pushing the IPS at at some point they got some kind of feedback but I think this is the essence we would need to change to make this better yeah so they

Martin Holst Swende: approval going forward needs to be very explicit and needs to have the actual client about groups present to do that

it's a little low if you could speak it to the first louder

it's reasonable I think so I experienced this on the other end as part of the Blake to be proposal that I was begging people for feedback and then and part of part of what happened is it took like almost three months for it to be merged to draft and no one really cares if something does that it doesn't exist and like a lot it was so and something that's something I really want to think about as part of hard for coordination is how are we going to bubble Oh should be looked at more closed each centric process gives this gradation of yeah we should look more closely at this we should look more

closely at this and having some form of schedule or a formal way to do that full open to and would love more ideas and to talk with you about it Alex Danna did you have something I was just going to say that I thought if the first one was to get the high level rather than the low level details the in general approval was to say that awkward days were like yeah this is a good idea go ahead and get the final specification and implementation and then at that point when there's a client implementing it we can have the details I'm I wasn't expecting that the first step would be full approval of the full API and all

that so you know if someone came with the proposal let's change the EVM I could replace it with JVM bytecode that golfer desk and say that's a bad idea building track versus if it's something smaller like I think we should support this specific change in this series of opcodes they say it sounds like a good idea a minute all right figure it out you come back and say this is specifically what it looks like it here's a test cases that was my understanding may not have been what everyone else is understanding about the process will be done mine

Alex Beregszaszi: would be similar but I think this also depends on the change because some changes might be small enough contained enough that we we can on unlike if there is only an abstract or maybe a really

short specification it would be enough to to give a blessing but some others may be so complex that you know it may look like okay they make the implementation and it turns out it has to be changed entirely and and then we may end up in a couple of cycles you know giving feedback and and the champion changing everything I'm not sure if we can get this right in there the first run anyway but I think it depends on on this scope of the actually IP some will be easier to deal with

and others may be just too big to give proper feedback okay so in summary this is

Hudson Jameson: all good things for us to think about

and I have hope for the future of this process improving

next up we have testing updates Demetri and Martin or anyone else who is doing testing related things with their clients any updates [Music] someone needs to hate the merge Partin and gather a few merged because I think

I have already reviews and testing comments so just a reminder yeah I think also

Martin Holst Swende: 1884 I made a PR to make it a couple of weeks ago

oh this this is the IPS right not the code oh okay sorry can you all

Hudson Jameson: ping me and I can make sure to make those final as long as there's nothing from the Nik software preventing it from going final

that'd be great or actually me or I guess Alex can do it okay and any other testing updates are

we good to meet ya there was official destinies

Dimitry Khokhlov: and part of those tests were created by the goal client and the goal client currently passing the blockchain test the state test mmm and every other client should download it updating runs through that test before the hard fork also all tests were moved to the legacy test folder those tests you need to check if it's affected by any of the implementation of the new hard for because like you cool you could break something is an implementation of a new

changes in a previous work so legacy test adjustment that was the previous part work rules to check that they are not affected and yes I would like to see more tests not just the basic coverage of the EAP so now every client developer is I'm welcome to write more test cases

misery death situation goal client and busy client fully compatible with retested eh now you could write a state test transition test I do have one update so there's a new hive that's been deployed it has changed

the URL and I posted it to the old court of get your channel if you want to check it out but it's running around the clock always pulling the latest test the tester poster and the latest and so far I think if imperative clients that's it okay just to go over decisions from last meeting the ice age EAP will not be included in Istanbul Oh stupid phone will not be include an Istanbul seems like there's no major reason to do it now should give us enough time to plan for another four and not delay Istanbul

according to James's calculations and the other one was bring your objections to the all core debs in two weeks if anyone is opposing the gift in defining eath 64 as the fork ID thing and rolling it out from EIP 21:24 we already talked about that cat herders are gonna reach out to the Gourley team to make sure that there are clear communication about node upgrades for Istanbul is one action item and the other one is that David palm will talk to way to see if 2200 should be self-contained way did you talk to David palm by chance and already I believe it's route already because 200

is self content at this moment great okay any client updates that want to any clients that want to give an update about anything important of theirs or anything like that that's the last thing okay great I think we're ending about half an hour early unless there's any other updates yeah this is Brent just just a quick notes taking we're taking notes this time but as far as identifying people here I'm seeing Carol Lib I apologize for not knowing people but sometimes when you use aliases and people I think are referring to you as

Peter is or as Carol Aird Peter oh I I'm sorry about that usually every time I join the meeting I rename myself but the transit today I forgot apologies okay so how would you like to be listed in the attendees as Peter and what's your last name might I ask I'll write it down okay yeah it's a complicated name to write appreciate that and also just a comment on formalizing the process of um getting AI P's approved one of the things you mentioned as some VIPs

Brent Allsop: need lots of review and other please don't need lots to review and and we need to track how many people are reviewed it and when

people review that if they find a problem how do you formalize that tracking anyway just a mention for canonize er that's exactly what canonize er is designed for for example you could create a topic for any IP and you can have the description of what that topic is and I'll pointer to the spec of the e IP and then you can have people once they reviewed it they can basically sign that petition or join that camp and you could have a whitelist of people that are approved to review an e IP and then you could you use a canon Iser algorithm that would only count their vote and so you can see okay now we've got six approved people that can approve things that have approved this I've reviewed and reprove this and also if someone

sees a problem with an e IP there is currently no formalized way for someone to communicate that other than to just go to all the forums and start yelling

and stuff like that yeah having a sense nice place for that would be a good idea but I think as far as canonize er goes I think I talked to you at Def Con about organizer a little bit and I think that what you should do is have a test what's called like a test vote or whatever it's called in the Canon Iser platform and put that in the etherium magicians forum and specifically on the page for the Tim created or Dano created I forgot which one for the upgrade process that process

for the train station I P centric model that's an ethereal magicians and it is on the first comment on the agenda there's a link to it and it's under train station oh so so where is that again on number three on Tim beykoz comments oh and the agenda the time that's coming in is in the zoom chat nope in the agenda on the PM repo agenda for the PA yeah sorry I'm not familiar with that so the agenda for the Pete for the PM repo and you know what I'll reach out to you and send it thank you so much I appreciate that sorry if I'm taking up oh great got it thanks so much

yep all right cool I think we're all good anything else so maybe I'm not sure we want to discuss this now but maybe make a call for the next call there were a bunch of each them we already moved to tentatively accepted for Berlin and I think there was like some controversy around pretty much all of them so I know that this summer wouldn't do a whole bunch of them Peter you had a whole lot of comments that Marlin this morning you had a comment about Thank You 62 and then there's obviously frog cow which is another one which people have thoughts on I think we shouldn't please try to figure out how we're gonna get through

all those discussions yeah yeah and we're gonna have a meeting in a week and I think that'll be the perfect time to talk about that okay a week from now and cuz yeah we can just kind of that'll be the main topic of next week's meeting cuz we'll have the fork number by then and that way we'll get back on track with the meeting times the reason we had a meeting this week was so that we would stay at the same cadence as being one week off from the earth 2.0 implementers meetings without having to have a weird skip week with the community that's like if like or at least reach out to the champions of

those eats and discuss yeah can someone do that I'd be really amazing if someone could jump in and just let some of the champions know I don't know how many are accepted so it might be too big of a task I think there's only five verse six and they're not accepted okay we'll talk about it on the Gator channel if not I can probably do it a little bit good idea good idea Oh James are you gonna say something you're under me yeah I can

do that if no one responds that obviously will say something about the state of the IP okay sounds great sounds great and to be clear the call is next Friday it's not two weeks from now yes it is next Friday quick question maybe I missed it since we kind of picked when we would like me not to make the may not assemble support for the current does anyone is anyone willing to do the block numbers we were gonna discuss that on get her once we like kind of start doing some calculations awesome all right thanks

everybody have a great weekend bye [Music] you [Music] [Music]

[Music] [Music] [Music] [Music] [Applause]

[Music] [Music]

[Music] [Music]

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.