From af4d2fd6bf1882da1853875039c60e41b6b95474 Mon Sep 17 00:00:00 2001 From: pudongair <744355276@qq.com> Date: Tue, 23 Jul 2024 01:15:09 +0900 Subject: [PATCH] chore: fix some comments (#3206) Signed-off-by: pudongair <744355276@qq.com> Co-authored-by: MSalopek --- RELEASE_PROCESS.md | 2 +- docs/docs/architecture/adr/adr-001-interchain-accounts.md | 2 +- docs/docs/architecture/adr/adr-003-ica-controller.md | 2 +- docs/docs/governance/best-practices.md | 2 +- docs/docs/governance/formatting.md | 2 +- tests/e2e/e2e_exec_test.go | 2 +- tests/e2e/scripts/hermes_bootstrap.sh | 4 ++-- 7 files changed, 8 insertions(+), 8 deletions(-) diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md index 760cb7fdedd..e8aedfd9e2a 100644 --- a/RELEASE_PROCESS.md +++ b/RELEASE_PROCESS.md @@ -242,7 +242,7 @@ The intention of the Stable Release Policy is to ensure that all major release s are maintained with the following categories of fixes: - Tooling improvements (including code formatting, linting, static analysis and updates to testing frameworks) -- Performance enhancements for running archival and synching nodes +- Performance enhancements for running archival and syncing nodes - Test and benchmarking suites, ensuring that fixes are sound and there are no performance regressions - Library updates including point releases for core libraries such as IBC-Go, Cosmos SDK, Tendermint and other dependencies - General maintenance improvements, that are deemed necessary by the stewarding team, that help align different releases and reduce the workload on the stewarding team diff --git a/docs/docs/architecture/adr/adr-001-interchain-accounts.md b/docs/docs/architecture/adr/adr-001-interchain-accounts.md index 30f0b57abf3..906ec81bc2b 100644 --- a/docs/docs/architecture/adr/adr-001-interchain-accounts.md +++ b/docs/docs/architecture/adr/adr-001-interchain-accounts.md @@ -47,7 +47,7 @@ There are future releases of Interchain Accounts which are expected to be backwa ## Development - Integration requirements - - Development has occured in [IBC-go](https://github.com/cosmos/ibc-go) and progress tracked on the project board there. + - Development has occurred in [IBC-go](https://github.com/cosmos/ibc-go) and progress tracked on the project board there. - Testing (Simulations, Core Team Testing, Partner Testing) - Simulations and Core Team tested this module - Audits (Internal Dev review, Third-party review, Bug Bounty) diff --git a/docs/docs/architecture/adr/adr-003-ica-controller.md b/docs/docs/architecture/adr/adr-003-ica-controller.md index 3a5dfd93314..7ffa81e87ce 100644 --- a/docs/docs/architecture/adr/adr-003-ica-controller.md +++ b/docs/docs/architecture/adr/adr-003-ica-controller.md @@ -18,7 +18,7 @@ Enabling the ICA Controller module on the Hub would support various use cases. O ## Decision -The ICA Controller module will be included in the application, so the Hub will have both ICA Host and Controller modules. The implementation will use the Controller module's built-in authentication mechanism, since we don't have a need for custom authentication logic. According to this, users will directly use `MsgRegisterInterchainAccount` and `MsgSendTx` messages defined by the Controller module. The possibility provided by the Controller module to define underlaying application to have custom processing of IBC messages exchanged by the Controller module (e.g. `OnChanOpenInit`, `OnAcknowledgementPacket`, etc.) will not be used, since there is currently no need for this. +The ICA Controller module will be included in the application, so the Hub will have both ICA Host and Controller modules. The implementation will use the Controller module's built-in authentication mechanism, since we don't have a need for custom authentication logic. According to this, users will directly use `MsgRegisterInterchainAccount` and `MsgSendTx` messages defined by the Controller module. The possibility provided by the Controller module to define underlying application to have custom processing of IBC messages exchanged by the Controller module (e.g. `OnChanOpenInit`, `OnAcknowledgementPacket`, etc.) will not be used, since there is currently no need for this. ```go // ICA Controller keeper diff --git a/docs/docs/governance/best-practices.md b/docs/docs/governance/best-practices.md index cbaa156ed91..12222cce501 100644 --- a/docs/docs/governance/best-practices.md +++ b/docs/docs/governance/best-practices.md @@ -77,7 +77,7 @@ It will be important to balance two things: being detailed and being concise. Yo Each major proposal type has a rough template available on the forum: [Text](https://forum.cosmos.network/t/about-the-signaling-text-category/5947), [community pool spend](https://forum.cosmos.network/t/about-the-community-spend-category/5949), [parameter change](https://forum.cosmos.network/t/about-the-parameter-change-category/5950), [software upgrade](https://forum.cosmos.network/t/about-the-software-upgrade-category/5951). -Each proposal should contain a summmary with key details about what the proposal hopes to change. If you were viewing only the summary with no other context, it should be a good start to being able to make a decision. +Each proposal should contain a summary with key details about what the proposal hopes to change. If you were viewing only the summary with no other context, it should be a good start to being able to make a decision. Assume that many people will stop reading at this point. However it is important to provide in-depth information. The on-chain proposal text should also include a link to an un-editable version of the text, such as an IPFS pin, and a link to where discussion about the idea is happening. diff --git a/docs/docs/governance/formatting.md b/docs/docs/governance/formatting.md index 4ec6952d8b0..b87871f31ef 100644 --- a/docs/docs/governance/formatting.md +++ b/docs/docs/governance/formatting.md @@ -93,7 +93,7 @@ You can update these CosmosHub modules using `submit-legacy-proposal`: * provider ::: -**Note:** The chages outlined here must be submitted using `submit-legacy-proposal`. +**Note:** The changes outlined here must be submitted using `submit-legacy-proposal`. For `param-change` proposals, there are arguably seven (7) components, though three are nested beneath 'Changes': diff --git a/tests/e2e/e2e_exec_test.go b/tests/e2e/e2e_exec_test.go index 9e224828d0d..1fcc4dd8ac7 100644 --- a/tests/e2e/e2e_exec_test.go +++ b/tests/e2e/e2e_exec_test.go @@ -707,7 +707,7 @@ func (s *IntegrationTestSuite) executeHermesCommand(ctx context.Context, hermesC if err != nil { return nil, fmt.Errorf("hermes relayer command returned failed with error: %s", err) } - // errors are catched by observing the logs level in the stderr output + // errors are caught by observing the logs level in the stderr output if lvl := out["level"]; lvl != nil && strings.ToLower(lvl.(string)) == "error" { errMsg := out["fields"].(map[string]interface{})["message"] return nil, fmt.Errorf("hermes relayer command failed: %s", errMsg) diff --git a/tests/e2e/scripts/hermes_bootstrap.sh b/tests/e2e/scripts/hermes_bootstrap.sh index d8fd93a4714..689f7b4d2b7 100755 --- a/tests/e2e/scripts/hermes_bootstrap.sh +++ b/tests/e2e/scripts/hermes_bootstrap.sh @@ -55,7 +55,7 @@ store_prefix = 'ibc' max_gas = 6000000 gas_price = { price = 0.005, denom = 'uatom' } gas_multiplier = 1.5 -clock_drift = '1m' # to accomdate docker containers +clock_drift = '1m' # to accommodate docker containers trusting_period = '14days' trust_threshold = { numerator = '1', denominator = '3' } dynamic_gas_price = { enabled = true, multiplier = 1.3, max = 0.05 } @@ -73,7 +73,7 @@ store_prefix = 'ibc' max_gas = 6000000 gas_price = { price = 0.005, denom = 'uatom' } gas_multiplier = 1.5 -clock_drift = '1m' # to accomdate docker containers +clock_drift = '1m' # to accommodate docker containers trusting_period = '14days' trust_threshold = { numerator = '1', denominator = '3' } dynamic_gas_price = { enabled = true, multiplier = 1.3, max = 0.05 }