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

refactor: apply new gov/params structure #4

Merged
merged 1 commit into from
May 30, 2024

Conversation

hallazzang
Copy link
Contributor

@hallazzang hallazzang commented May 29, 2024

  • Remove x/params dependency
  • Remove legacy proposal handlers since we're not using x/gov
    • x/stakeibc had AddValidatorsProposal and ToggleLSMProposal before and there's no need to keep these two anymore
  • Applied new module parameters semantics

remove SetParams in some modules, because their parameters are empty.
it's still possible to rollback this behavior in the future
@hallazzang hallazzang self-assigned this May 29, 2024
@hallazzang hallazzang marked this pull request as ready for review May 30, 2024 06:13
@hallazzang hallazzang requested review from manu0466 and RiccardoM May 30, 2024 06:14
@hallazzang hallazzang changed the title refactor: change module params structure refactor: apply new gov/params structure May 30, 2024
Copy link
Contributor

@manu0466 manu0466 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@RiccardoM RiccardoM merged commit 978cac5 into main May 30, 2024
15 checks passed
@RiccardoM RiccardoM deleted the hallazzang/refactor-params branch May 30, 2024 14:51
hallazzang added a commit that referenced this pull request May 31, 2024
RiccardoM pushed a commit that referenced this pull request Jun 6, 2024
continued from #4

<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

-->

<!--
Please provide clear motivation for your patch and explain how it
improves
initia user experience or initia developer experience
significantly:

* Any test improvements or new tests that improve coverage are always
welcome.
* All other changes should have accompanying unit tests (see
`src/test/`) or
functional tests (see `test/`). Contributors should note which tests
cover
modified code. If no tests exist for a region of modified code, new
tests
  should accompany the change.
* Bug fixes are most welcome when they come with steps to reproduce or
an
explanation of the potential issue as well as reasoning for the way the
bug
  was fixed.
* Features are welcome, but might be rejected due to design or scope
issues.
If a feature is based on a lot of dependencies, contributors should
first
  consider building the system outside of initia, if possible.
-->

<!--
Initia has a thorough review process and even the most trivial change
needs to pass a lot of eyes and requires non-zero or even substantial
time
effort to review. There is a huge lack of active reviewers on the
project, so
patches often sit for a long time.
-->
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.

3 participants