-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design Review Meeting for Doc 153 #164
Comments
We have 3 people RSVP'ed from it, and I invited everyone from this thread to it. I thought I set the google meet option to public on the calendar, and it is linked here. I can delay it if there is anyone who wants to attend that can't make it, but I think all relevant people should be notified? |
I don't see it on the calendar though. |
Oh I see, you created an event, got it. Normally they go into the public calendar |
I'd keep just keep it this time then if enough of the right people will be there. |
Meeting recording can be found here |
Hi All - It looks like this one is taken care of but just to clarify: If you use the Design Review template when creating the issue it should auto-assign the issue to me and then I can get it on the calendar. @ControlCplusControlV let me know if you used the template and it failed to assign me and I can look into it. That said, when there is less than 24hr notice it may be more expedient to just book it yourself so that I do not become a roadblock due to timezone, etc ... Please let me know if you have any questions and thank you for handling! I will get this recording to Amanda to post on our youtube shortly. |
Ah, I had used the template but took it upon myself to make the meeting which is where I think it went wrong. I did check everybody's calendar though to ensure no conflicts, but the meeting settings may have been a bit off, will keep this in mind for future meetings though! |
All good and no worries on my side! As long as the meeting got booked then it is all good ;-) |
Design Doc for Doc 153
Review meeting for the Proposal to flatten immutable arguments within the DisputeGame, so that new deployments can use proxies instead of requiring full redeployments of the proofs system.
Date, Time and Duration
Design Doc 153
Tuesday, November 26
10:00-10:30am EST
Video call link: https://meet.google.com/hhm-gwjj-xtb
Or dial: (TH) +66 2 844 9331 PIN: 819 416 503 3020#
More phone numbers: https://tel.meet/hhm-gwjj-xtb?pin=8194165033020
Link to design doc
#153
Additional Context
Multiple implementations were discussed, at first the proposal was to flatten all constructor arguments as immutable args provided by the factory and stored in an associated config mapping. However, due to Solidity's limitations, this would be a generic blob of bytes, to which an
IExtraDataFiller
contract was suggested to properly store the args, beforeCreator
contracts were settled on to deploy newDisputeGame
s.Requested Attendees
@ajsutton @clabby @maurelian @smartcontracts
The text was updated successfully, but these errors were encountered: