-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Rename Parathreads -> On-demand Parachains #5858
Conversation
@CrackTheCode016 let me know if these changes make sense to you. See the attached issue by @Overkillus |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very good refactor, thank you! We can further improve more of the explainations in further PRs, but this is really great to clarify right now 🙏
The only reason I did not approve was the use of the word "permanent" - I'm not sure it is entirely accurate, perhaps it would be better to allude to bulk coretime instead. However, I could be wrong here.
less scalable, and parathreads in particular may not receive messages due to excessive queue | ||
growth. | ||
less scalable, and on-demand parachains in particular may not receive messages due to excessive | ||
queue growth. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious if this is indeed the case, not sure how queue is managed in relation to on-demand (I suspect it's the same, still good to check probably though)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure, I did not touch that sentence if not just for swapping parathread <-> on-demand parachain
@CrackTheCode016 I implemented your feedback. Added @DrW3RK as a secondary reviewer to provide final feedback before merging. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks overall fine, thanks! I see that "permanent" is still being used in a few places, however I will leave the final review to Radha to decide.
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
Co-authored-by: Radha <[email protected]>
@DrW3RK thanks for the final review. I noticed you added coretime in a few pages although not deployed on Polkadot yet. I approved all suggestions and there will be a few places still mentioning auctions. Resolved a few conflicts and merging this. |
Right. Considering these docs also render on the Kusama guide, I mentioned coretime where necessary (especially, with on-demand parachains which only make sense with coretime in picture). We can change those to conditionally render through a follow-up PR (if it is worth the effort) or wait till Agile Coretime goes live on Polkadot to just eliminate all the references to slots/leases when. |
learn-parachains