Skip to content
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

Software Release CAIP #238

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

null-ref-ex
Copy link

A proposal on how we can lay a solid foundation for requesting chain software information alongside a standard data structure for response payloads. The hope is that this can lay a foundation on which systems can be built that address ongoing issues for node runners and validator operators know about and automatically executing on software release events.

A proposal on how we can lay a solid foundation for requesting chain software information alongside a standard data structure for response payloads.
The hope is that this can lay a foundation on which systems can be built that address ongoing issues for node runners and validator operators know about and automatically executing on software release events.
@bumblefudge
Copy link
Collaborator

Hey sorry I'm a little lost on context here. Is this Ethereum-specific? Would it make sense to try to get support for this in, say, the AllCoreDevs discord of the Ethereum Foundation if so, or in the equivalent repo/community forum where protocol upgrades are designed and aligned in some other namespace first, and then bring a generalized v2 back afterwards with some implementer feedback and lessons learned?

@null-ref-ex
Copy link
Author

It is not ethereum specific, the problem exists in every network as far as I've experienced.
I was hoping to use this process to establish a well thought out and constructed standard on which implementations can be built.

@bumblefudge
Copy link
Collaborator

OK! Is there anything similar implemented in the wild that this is an improvement on? Or do you know of other VMs/ecosystems/"namespaces" that have a use-case for this and are interested in specifying it before or after implementing? If you look in the open PRs, there are a few other, similar ideas (many of them authored by me!) which are similarly waiting for an implementer-champion, because we prefer not to specify pure greenfield at CASA, so much as things that at least 1, preferably 2 independent implementations are at least softly-commited to taking to production...

@null-ref-ex
Copy link
Author

Sounds good! I'll take a look through and see what I can find.
Do you have any time to have a conversation online? I'd love to understand everything better so I can be a more constructive contributor along with my team.

@bumblefudge
Copy link
Collaborator

bumblefudge commented Aug 7, 2023

absolutely! feel free to book something at cal.com/ and bring as much or as little of your team as you think would be constructive 😄

@bumblefudge
Copy link
Collaborator

absolutely! feel free to book something at cal.com/ and bring as much or as little of your team as you think would be constructive 😄

whoops my cal.com was misconfigured and swallowing requests without throwing, if you already made an appointment it was lost. could I ask you to try again if so?

@bumblefudge
Copy link
Collaborator

@null-ref-ex any progress here? i'll be in US time zones starting in 2 weeks so glad to take any joint calls with partners that are curious about the idea. apologies that I forgot about this and didn't ask around at Devconnect like I hoped to!

@mozz30-tech
Copy link

A proposal on how we can lay a solid foundation for requesting chain software information alongside a standard data structure for response payloads. The hope is that this can lay a foundation on which systems can be built that address ongoing issues for node runners and validator operators know about and automatically executing on software release events.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants