From 78fbdbb49749e9c2381397296e388df641798d2a Mon Sep 17 00:00:00 2001 From: rootdiae Date: Fri, 10 Jan 2025 10:40:14 +0800 Subject: [PATCH] fix typos --- documentation/en/data-onboarding-visibility.md | 2 +- documentation/misc/Building_a_network_skeleton.md | 4 ++-- storage/sealer/README.md | 2 +- tools/kibana/README.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/documentation/en/data-onboarding-visibility.md b/documentation/en/data-onboarding-visibility.md index 3225753dd1d..346867a58fc 100644 --- a/documentation/en/data-onboarding-visibility.md +++ b/documentation/en/data-onboarding-visibility.md @@ -32,7 +32,7 @@ There are two possible additions to this flow: 💡 **The builtin market actor should not be used as single a source of truth regarding data onboarding activities.** The builtin market actor is only a source of truth for data onboarding mediated by the builtin market actor. -💡 **The builtin market actor should not be used as a source of truth regarding verified claims and metrics related to FIL+ usage (size, clients, profiders).** The `VerifiedClaim` property of `DealState` has been removed from the builtin market actor. Instead, the verified registry should be used as the only source of truth regarding both allocations and claims. +💡 **The builtin market actor should not be used as a source of truth regarding verified claims and metrics related to FIL+ usage (size, clients, providers).** The `VerifiedClaim` property of `DealState` has been removed from the builtin market actor. Instead, the verified registry should be used as the only source of truth regarding both allocations and claims. 💡 **Sector data commitments and their constituent pieces are only stored on chain in the verified registry claims in the case of verified data (pieces) onboarded in any mechanism (DDO and/or builtin market actor).** Piece information for data onboarded that is not verified ("sparkling data") and not mediated through the builtin market actor will only appear in messages and actor events. Messages and actor events may be used as a source of truth for data sector commitments. diff --git a/documentation/misc/Building_a_network_skeleton.md b/documentation/misc/Building_a_network_skeleton.md index 1fae76b923b..cb53b4698a7 100644 --- a/documentation/misc/Building_a_network_skeleton.md +++ b/documentation/misc/Building_a_network_skeleton.md @@ -101,7 +101,7 @@ There is a network skeleton in Lotus, which bubbles up all the other dependencie You can take a look at [this Ref-FVM PR as a reference](https://github.com/filecoin-project/ref-fvm/pull/2029), which added the skeleton for network version 24. You can also check out the [releasing primary FVM crates checklist here](https://github.com/filecoin-project/ref-fvm/blob/master/CONTRIBUTING.md#primary-fvm-crates) -2. In a seperate PR bump the Ref-FVM version: +2. In a separate PR bump the Ref-FVM version: - Bump the version in the root Cargo.toml file. - Bump the fvm, fvm_shared and fvm_sdk versions in the `workspace` section in `ref-fvm/cargo.toml` @@ -179,7 +179,7 @@ You can take a look at [this PR as a reference](https://github.com/filecoin-proj 👉 You can take a look at this [Filecoin-FFI PR as a reference](https://github.com/filecoin-project/filecoin-ffi/pull/481), which was for network version 24. -Note: one only needs to update `filecion-ffi`'s dependency on `go-state-types` when a network upgrade is introducing new types in `go-state-types` (see [below](#new-types-in-go-state-types)). Otherwise, `filecion-ffi`'s dependency on `go-state-types` is just updated when doing fiinal releases before the network upgrade. +Note: one only needs to update `filecion-ffi`'s dependency on `go-state-types` when a network upgrade is introducing new types in `go-state-types` (see [below](#new-types-in-go-state-types)). Otherwise, `filecion-ffi`'s dependency on `go-state-types` is just updated when doing final releases before the network upgrade. ## Lotus Checklist diff --git a/storage/sealer/README.md b/storage/sealer/README.md index b90a9ebd0b7..186e536913b 100644 --- a/storage/sealer/README.md +++ b/storage/sealer/README.md @@ -5,7 +5,7 @@ > a concrete implementation of the [specs-storage](https://github.com/filecoin-project/specs-storage) interface -The sector-storage project provides a implementation-nonspecific reference implementation of the [specs-storage](https://github.com/filecoin-project/specs-storage) interface. +The sector-storage project provides an implementation-nonspecific reference implementation of the [specs-storage](https://github.com/filecoin-project/specs-storage) interface. ## Disclaimer diff --git a/tools/kibana/README.md b/tools/kibana/README.md index c556ae10cf5..728a9894c39 100644 --- a/tools/kibana/README.md +++ b/tools/kibana/README.md @@ -6,7 +6,7 @@ throughout Filecoin network. ### Importing index template Index template needs to be imported into Elasticsearch for score weights and to -prevent Elasticsearch from infering wrong field type. +prevent Elasticsearch from inferring wrong field type. The [template](./index-template.json) is loaded via [Kibana Index Management](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-mgmt.html) and pasted into newly created Index Template.