Merge pull request #16873 from MinaProtocol/amcie-merging-release-to-master

Merging 3.1.0 release branch to master

Author: amc-ie

.mailmap

@@ -20,10 +20,10 @@
 /src/app/runtime_genesis_ledger/ @MinaProtocol/protocol-eng-reviewers
 /src/app/archive_blocks/ @MinaProtocol/protocol-eng-reviewers
 /src/app/extract_blocks/ @MinaProtocol/protocol-eng-reviewers
-/src/app/rosetta/ @MinaProtocol/mina-foundation-eng
-/src/lib/rosetta_coding/ @MinaProtocol/mina-foundation-eng
-/src/lib/rosetta_lib/ @MinaProtocol/mina-foundation-eng
-/src/lib/rosetta_models/ @MinaProtocol/mina-foundation-eng
+/src/app/rosetta/ @MinaProtocol/protocol-eng-reviewers
+/src/lib/rosetta_coding/ @MinaProtocol/protocol-eng-reviewers
+/src/lib/rosetta_lib/ @MinaProtocol/protocol-eng-reviewers
+/src/lib/rosetta_models/ @MinaProtocol/protocol-eng-reviewers
 
 /src/lib/ @MinaProtocol/protocol-eng-reviewers
 

CODEOWNERS

@@ -48,7 +48,7 @@ Whenever a hard fork happens, the code in the corresponding release branch, e.g.
 - The intention is then to again have `compatible` as a next soft-fork branch.
   - The transition will be gradual: right after HF, `berkeley` will be copied into both `master` *and* `compatible`, and `develop` will remain as is for a while. PRs from `develop` will be gradually picked based on release scope and included in `compatible` for subsequent soft-fork releases.
   - The pre-Berkeley `compatible` is entirely discarded. The pre-Berkeley branch `berkeley` is completely removed from both `mina` and `proof-systems`.
-- `release/1.X.X` branches are made off of `compatible` and tagged with alpha and beta tags until the code is deemed stable, then the `release/1.X.X` branch is merged into `master` and given a stable tag. Whenever code is tagged, if anything is missing in in the downstream branches (compatible, develop) then the tagged branch is also merged back for consistency.
+- `release/1.X.X` branches are made off of `compatible` and tagged with alpha and beta tags until the code is deemed stable, then the `release/1.X.X` branch is merged into `master` and given a stable tag. Whenever code is tagged, if anything is missing in the downstream branches (compatible, develop) then the tagged branch is also merged back for consistency.
 
 ## Day to day: which branch should I use?
 

README-branching.md

@@ -46,7 +46,7 @@ In this case, you should:
    [Google Cloud](https://console.cloud.google.com/gcr/images/o1labs-192920/global/mina-toolchain)
    where they have been automatically uploaded. Look for your branch name and
    commit hash in the second column. You should find several images suffixed
-   with `-bullseye` and `-focal` (Debian versions).
+   with `-bullseye` or `-focal` (Debian versions).
 3. For each such image, retrieve its full name and hash by hovering its link and
    clicking the `Copy full image name` tooltip that appears (or retrieve it on
    the image's page).

README-ci-failures.md

@@ -261,7 +261,7 @@ Debian package can be build locally by using below commands:
 ```
 make build
 ```
-2. Build debian for mina-devet (example for ubuntu 18.04):
+2. Build debian for mina-devnet (example for ubuntu 18.04):
 ```
 ./scripts/debian/build.sh daemon_devnet
 ```

README-dev.md

@@ -29,7 +29,7 @@ The Mina implementation of the Rosetta API offers a more stable and useful inter
 - [Mina Protocol](https://docs.minaprotocol.com/) documentation
 - [Installing and using a third-party wallet](https://docs.minaprotocol.com/using-mina/install-a-wallet)
 - [Sending a Payment using Mina's CLI](https://docs.minaprotocol.com/node-operators/sending-a-payment)
-- [Become a Node Operator](https://minaprotocol.com/docs/getting-started/)
+- [Become a Node Operator](https://docs.minaprotocol.com/node-operators/block-producer-node/getting-started)
 
 ### Technical Papers
 

README.md

@@ -264,11 +264,11 @@ There are several public Grafana dashboards available here:
 
 The purpose of a public testnet is to allow end-users to try out the software and learn how to operate it. Thus, we accept sign-ups for stake to be allocated in the genesis, and commit those keys to the compiled genesis ledger.
 
-For context, these keys correspond to the "Fish Keys" in the QA Net deployments, and Online Fish Keys are ommitted in a Public Testnet deployment and "Offline Fish Keys" are instead delegated to the submitted User Keys.
+For context, these keys correspond to the "Fish Keys" in the QA Net deployments, and Online Fish Keys are omitted in a Public Testnet deployment and "Offline Fish Keys" are instead delegated to the submitted User Keys.
 
 ### Generate Genesis Ledger
 
-Once you have the keys for your deploymenet created, and the Staker Keys saved to a CSV, you can use them to generate a genesis ledger with the following command.
+Once you have the keys for your deployment created, and the Staker Keys saved to a CSV, you can use them to generate a genesis ledger with the following command.
 
 ```
 scripts/generate-keys-and-ledger.sh