style: lint go and markdown (#10060)

## Description + fixing `x/bank/migrations/v44.migrateDenomMetadata` - we could potentially put a wrong data in a new key if the old keys have variable length. + linting the code Putting in the same PR because i found the issue when running a linter. Depends on: #10112 --- ### Author Checklist *All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.* I have... - [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [x] added `!` to the type prefix if API or client breaking change - [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting)) - [ ] provided a link to the relevant issue or specification - [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] updated the relevant documentation or specification - [ ] reviewed "Files changed" and left comments if necessary - [ ] confirmed all CI checks have passed ### Reviewers Checklist *All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.* I have... - [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] confirmed `!` in the type prefix if API or client breaking change - [ ] confirmed all author checklist items have been addressed - [ ] reviewed state machine logic - [ ] reviewed API design and naming - [ ] reviewed documentation is accurate - [ ] reviewed tests and test coverage - [ ] manually tested (if applicable) (cherry picked from commit 479485f) # Conflicts: # CODING_GUIDELINES.md # CONTRIBUTING.md # STABLE_RELEASES.md # contrib/rosetta/README.md # cosmovisor/README.md # crypto/keyring/keyring.go # db/README.md # docs/404.md # docs/DOCS_README.md # docs/architecture/adr-038-state-listening.md # docs/architecture/adr-040-storage-and-smt-state-commitments.md # docs/architecture/adr-043-nft-module.md # docs/architecture/adr-044-protobuf-updates-guidelines.md # docs/architecture/adr-046-module-params.md # docs/migrations/pre-upgrade.md # docs/migrations/rest.md # docs/ru/README.md # docs/run-node/rosetta.md # docs/run-node/run-node.md # docs/run-node/run-testnet.md # go.mod # scripts/module-tests.sh # snapshots/README.md # store/streaming/README.md # store/streaming/file/README.md # store/v2/flat/store.go # store/v2/smt/store.go # x/auth/ante/sigverify.go # x/auth/middleware/basic.go # x/auth/spec/01_concepts.md # x/auth/spec/05_vesting.md # x/auth/spec/07_client.md # x/authz/spec/05_client.md # x/bank/spec/README.md # x/crisis/spec/05_client.md # x/distribution/spec/README.md # x/epoching/keeper/keeper.go # x/epoching/spec/03_to_improve.md # x/evidence/spec/07_client.md # x/feegrant/spec/README.md # x/gov/spec/01_concepts.md # x/gov/spec/07_client.md # x/group/internal/orm/spec/01_table.md # x/mint/spec/06_client.md # x/slashing/spec/09_client.md # x/slashing/spec/README.md # x/staking/spec/09_client.md # x/upgrade/spec/04_client.md
cosmos · Oct 30, 2021 · b1718a7 · b1718a7
1 parent 0ac1f6d
commit b1718a7
Show file tree

Hide file tree

Showing 58 changed files with 8,170 additions and 14 deletions.
diff --git a/CODING_GUIDELINES.md b/CODING_GUIDELINES.md
@@ -0,0 +1,89 @@
+# Coding Guidelines
+
+This document is an extension to [CONTRIBUTING](./CONTRIBUTING.md) and provides more details about the coding guidelines and requirements.
+
+## API & Design
+
++ Code must be well structured:
+    + packages must have a limited responsibility (different concerns can go to different packages),
+    + types must be easy to compose,
+    + think about maintainbility and testability.
++ "Depend upon abstractions, [not] concretions".
++ Try to limit the number of methods you are exposing. It's easier to expose something later than to hide it.
++ Take advantage of `internal` package concept.
++ Follow agreed-upon design patterns and naming conventions.
++ publicly-exposed functions are named logically, have forward-thinking arguments and return types.
++ Avoid global variables and global configurators.
++ Favor composable and extensible designs.
++ Minimize code duplication.
++ Limit third-party dependencies.
+
+Performance:
+
++ Avoid unnecessary operations or memory allocations.
+
+Security:
+
++ Pay proper attention to exploits involving:
+    + gas usage
+    + transaction verification and signatures
+    + malleability
+    + code must be always deterministic
++ Thread safety. If some functionality is not thread-safe, or uses something that is not thread-safe, then clearly indicate the risk on each level.
+
+## Testing
+
+Make sure your code is well tested:
+
++ Provide unit tests for every unit of your code if possible. Unit tests are expected to comprise 70%-80% of your tests.
++ Describe the test scenarios you are implementing for integration tests.
++ Create integration tests for queries and msgs.
++ Use both test cases and property / fuzzy testing. We use the [rapid](pgregory.net/rapid) Go library for property-based and fuzzy testing.
++ Do not decrease code test coverage. Explain in a PR if test coverage is decreased.
+
+We expect tests to use `require` or `assert` rather than `t.Skip` or `t.Fail`,
+unless there is a reason to do otherwise.
+When testing a function under a variety of different inputs, we prefer to use
+[table driven tests](https://github.com/golang/go/wiki/TableDrivenTests).
+Table driven test error messages should follow the following format
+`<desc>, tc #<index>, i #<index>`.
+`<desc>` is an optional short description of whats failing, `tc` is the
+index within the test case table that is failing, and `i` is when there
+is a loop, exactly which iteration of the loop failed.
+The idea is you should be able to see the
+error message and figure out exactly what failed.
+Here is an example check:
+
+```go
+<some table>
+for tcIndex, tc := range cases {
+  <some code>
+  resp, err := doSomething()
+  require.NoError(err)
+  require.Equal(t, tc.expected, resp, "should correctly perform X")
+```
+
+## Quality Assurance
+
+We are forming a QA team that will support the core Cosmos SDK team and collaborators by:
+
+- Improving the Cosmos SDK QA Processes
+- Improving automation in QA and testing
+- Defining high-quality metrics
+- Maintaining and improving testing frameworks (unit tests, integration tests, and functional tests)
+- Defining test scenarios.
+- Verifying user experience and defining a high quality.
+    - We want to have **acceptance tests**! Document and list acceptance lists that are implemented and identify acceptance tests that are still missing.
+    - Acceptance tests should be specified in `acceptance-tests` directory as Markdown files.
+- Supporting other teams with testing frameworks, automation, and User Experience testing.
+- Testing chain upgrades for every new breaking change.
+    - Defining automated tests that assure data integrity after an update.
+
+Desired outcomes:
+
+- QA team works with Development Team.
+- QA is happening in parallel with Core Cosmos SDK development.
+- Releases are more predictable.
+- QA reports. Goal is to guide with new tasks and be one of the QA measures.
+
+As a developer, you must help the QA team by providing instructions for User Experience (UX) and functional testing.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -26,15 +26,30 @@ Contributing to this repo can mean many things such as participating in
 discussion or proposing code changes. To ensure a smooth workflow for all
 contributors, the general procedure for contributing has been established:
 
+<<<<<<< HEAD
 1. Either [open](https://github.com/cosmos/cosmos-sdk/issues/new/choose) or
    [find](https://github.com/cosmos/cosmos-sdk/issues) an issue you'd like to help with
 2. Participate in thoughtful discussion on that issue
 3. If you would like to contribute:
    1. If the issue is a proposal, ensure that the proposal has been accepted
+=======
+1. Start by browsing [new issues](https://github.com/cosmos/cosmos-sdk/issues) and [discussions](https://github.com/cosmos/cosmos-sdk/discussions). If you are looking for something interesting or if you have something in your mind, there is a chance it was has been discussed.
+
+- Looking for a good place to start contributing? How about checking out some [good first issues](https://github.com/cosmos/cosmos-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)?
+
+2. Determine whether a GitHub issue or discussion is more appropriate for your needs:
+1. If want to propose something new that requires specification or an additional design, or you would like to change a process, start with a [new discussion](https://github.com/cosmos/cosmos-sdk/discussions/new). With discussions, we can better handle the design process using discussion threads. A discussion usually leads to one or more issues.
+2. If the issue you want addressed is a specific proposal or a bug, then open a [new issue](https://github.com/cosmos/cosmos-sdk/issues/new/choose).
+3. Review existing [issues](https://github.com/cosmos/cosmos-sdk/issues) to find an issue you'd like to help with.
+3. Participate in thoughtful discussion on that issue.
+4. If you would like to contribute:
+   1. Ensure that the proposal has been accepted.
+>>>>>>> 479485f95 (style: lint go and markdown (#10060))
    2. Ensure that nobody else has already begun working on this issue. If they have,
       make sure to contact them to collaborate
    3. If nobody has been assigned for the issue and you would like to work on it,
       make a comment on the issue to inform the community of your intentions
+<<<<<<< HEAD
       to begin work
    4. Follow standard GitHub best practices: fork the repo, branch from the
       HEAD of `master`, make some commits, and submit a PR to `master`
@@ -49,28 +64,88 @@ contributors, the general procedure for contributing has been established:
       of `CHANGELOG.md` (see file for log format)
 
 Note that for very small or blatantly obvious problems (such as typos) it is
+=======
+      to begin work.
+5. To submit your work as a contribution to the repository follow standard GitHub best practices. See [pull request guideline](#pull-requests) below.
+
+**Note:** For very small or blatantly obvious problems such as typos, you are
+>>>>>>> 479485f95 (style: lint go and markdown (#10060))
 not required to an open issue to submit a PR, but be aware that for more complex
 problems/features, if a PR is opened before an adequate design discussion has
 taken place in a GitHub issue, that PR runs a high likelihood of being rejected.
 
+<<<<<<< HEAD
 Other notes:
 
 - Looking for a good place to start contributing? How about checking out some
   [good first issues](https://github.com/cosmos/cosmos-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
 - Please make sure to run `make format` before every commit - the easiest way
   to do this is have your editor run it for you upon saving a file. Additionally
   please ensure that your code is lint compliant by running `make lint-fix`.
+=======
+## Teams Dev Calls
+
+The Cosmos SDK has many stakeholders contributing and shaping the project. Regen Network Development leads the Cosmos SDK R&D, and welcomes long-term contributors and additional maintainers from other projects. We use self-organizing principles to coordinate and collaborate across organizations in structured "Working Groups" that focus on specific problem domains or architectural components of the Cosmos SDK.
+
+The developers are organized in working groups which are listed on a ["Working Groups & Arch Process" Github Issue](https://github.com/cosmos/cosmos-sdk/issues/9058) (pinned at the top of the [issues list](https://github.com/cosmos/cosmos-sdk/issues)).
+
+The important development announcements are shared on [Discord](https://discord.com/invite/cosmosnetwork) in the \#dev-announcements channel.
+
+To synchronize we have few major meetings:
+
++ Architecture calls: bi-weekly on Fridays at 14:00 UTC (alternating with the grooming meeting below).
++ Grooming / Planning: bi-weekly on Fridays at 14:00 UTC (alternating with the architecture meeting above).
++ Cosmos Community SDK Development Call on the last Wednesday of every month at 17:00 UTC.
++ Cosmos Roadmap Prioritization every 4 weeks on Tuesday at 15:00 UTC (limited participation).
+
+If you would like to join one of those calls, then please contact us on [Discord](https://discord.com/invite/cosmosnetwork) or reach out directly to Cory Levinson from Regen Network (cory@regen.network).
+
+## Architecture Decision Records (ADR)
+
+When proposing an architecture decision for the Cosmos SDK, please start by opening an [issue](https://github.com/cosmos/cosmos-sdk/issues/new/choose) or a [discussion](https://github.com/cosmos/cosmos-sdk/discussions/new) with a summary of the proposal. Once the proposal has been discussed and there is rough alignment on a high-level approach to the design, the [ADR creation process](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/PROCESS.md) can begin. We are following this process to ensure all involved parties are in agreement before any party begins coding the proposed implementation. If you would like to see examples of how these are written, please refer to the current [ADRs](https://github.com/cosmos/cosmos-sdk/tree/master/docs/architecture).
+
+## Development Procedure
+
+- The latest state of development is on `master`.
+- `master` must never fail `make lint test test-race`.
+- No `--force` onto `master` (except when reverting a broken commit, which should seldom happen).
+- Create a branch to start a wok:
+    - Fork the repo (core developers must create a branch directly in the Cosmos SDK repo),
+    branch from the HEAD of `master`, make some commits, and submit a PR to `master`.
+    - For core developers working within the `cosmos-sdk` repo, follow branch name conventions to ensure a clear
+    ownership of branches: `{moniker}/{issue#}-branch-name`.
+    - See [Branching Model](#branching-model-and-release) for more details.
+- Be sure to run `make format` before every commit. The easiest way
+  to do this is have your editor run it for you upon saving a file (most of the editors
+  will do it anyway using a pre-configured setup of the programming language mode).
+  Additionally, be sure that your code is lint compliant by running `make lint-fix`.
+>>>>>>> 479485f95 (style: lint go and markdown (#10060))
   A convenience git `pre-commit` hook that runs the formatters automatically
   before each commit is available in the `contrib/githooks/` directory.
 
 ## Architecture Decision Records (ADR)
 
+<<<<<<< HEAD
 When proposing an architecture decision for the SDK, please create an [ADR](./docs/architecture/README.md)
 so further discussions can be made. We are following this process so all involved parties are in
 agreement before any party begins coding the proposed implementation. If you would like to see some examples
 of how these are written refer to the current [ADRs](https://github.com/cosmos/cosmos-sdk/tree/master/docs/architecture).
 
 ## Pull Requests
+=======
+Before submitting a pull request:
+
+- merge the latest master `git merge origin/master`,
+- run `make lint test` to ensure that all checks and tests pass.
+
+Then:
+
+1. If you have something to show, **start with a `Draft` PR**. It's good to have early validation of your work and we highly recommend this practice. A Draft PR also indicates to the community that the work is in progress.
+   Draft PRs also helps the core team provide early feedback and ensure the work is in the right direction.
+2. When the code is complete, change your PR from `Draft` to `Ready for Review`.
+3. Go through the actions for each checkbox present in the PR template description. The PR actions are automatically provided for each new PR.
+4. Be sure to include a relevant changelog entry in the `Unreleased` section of `CHANGELOG.md` (see file for log format).
+>>>>>>> 479485f95 (style: lint go and markdown (#10060))
 
 PRs should be categorically broken up based on the type of changes being made (i.e. `fix`, `feat`,
 `refactor`, `docs`, etc.). The *type* must be included in the PR title as a prefix (e.g.

diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md
@@ -2,13 +2,85 @@
 
 *Stable Release Series* continue to receive bug fixes until they reach **End Of Life**.
 
+<<<<<<< HEAD:STABLE_RELEASES.md
 Only the following release series are currently supported and receive bug fixes:
+=======
+## Major Release Procedure
+
+A _major release_ is an increment of the first number (eg: `v1.2` → `v2.0.0`) or the _point number_ (eg: `v1.1 → v1.2.0`, also called _point release_). Each major release opens a _stable release series_ and receives updates outlined in the [Major Release Maintenance](#major-release-maintenance)_section.
+
+Before making a new _major_ release we do beta and release candidate releases. For example, for release 1.0.0:
+
+```
+v1.0.0-beta1 → v1.0.0-beta2 → ... → v1.0.0-rc1 → v1.0.0-rc2 → ... → v1.0.0
+```
+
+- Release a first beta version on the `master` branch and freeze `master` from receiving any new features. After beta is released, we focus on releasing the release candidate:
+    - finish audits and reviews
+    - kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks)
+    - perform functional tests
+    - add more tests
+    - release new beta version as the bugs are discovered and fixed.
+- After the team feels that the `master` works fine we create a `release/vY` branch (going forward known a release branch), where `Y` is the version number, with the patch part substituted to `x` (eg: 0.42.x, 1.0.x). Ensure the release branch is protected so that pushes against the release branch are permitted only by the release manager or release coordinator.
+    - **PRs targeting this branch can be merged _only_ when exceptional circumstances arise**
+    - update the GitHub mergify integration by adding instructions for automatically backporting commits from `master` to the `release/vY` using the `backport/Y` label.
+- In the release branch, prepare a new version section in the `CHANGELOG.md`
+    - All links must be link-ified: `$ python ./scripts/linkify_changelog.py CHANGELOG.md`
+    - Copy the entries into a `RELEASE_CHANGELOG.md`, this is needed so the bot knows which entries to add to the release page on GitHub.
+- Create a new annotated git tag for a release candidate  (eg: `git tag -a v1.1.0-rc1`) in the release branch.
+    - from this point we unfreeze master.
+    - the SDK teams collaborate and do their best to run testnets in order to validate the release.
+    - when bugs are found, create a PR for `master`, and backport fixes to the release branch.
+    - create new release candidate tags after bugs are fixed.
+- After the team feels the release branch is stable and everything works, create a full release:
+    - update `CHANGELOG.md`.
+    - create a new annotated git tag (eg `git -a v1.1.0`) in the release branch.
+    - Create a GitHub release.
+
+Following _semver_ philosophy, point releases after `v1.0`:
+
+- must not break API
+- can break consensus
+
+Before `v1.0`, point release can break both point API and consensus.
+
+## Patch Release Procedure
+
+A _patch release_ is an increment of the patch number (eg: `v1.2.0` → `v1.2.1`).
+
+**Patch release must not break API nor consensus.**
+
+Updates to the release branch should come from `master` by backporting PRs (usually done by automatic cherry pick followed by a PRs to the release branch). The backports must be marked using `backport/Y` label in PR for master.
+It is the PR author's responsibility to fix merge conflicts, update changelog entries, and
+ensure CI passes. If a PR originates from an external contributor, a core team member assumes
+responsibility to perform this process instead of the original author.
+Lastly, it is core team's responsibility to ensure that the PR meets all the SRU criteria.
+
+Point Release must follow the [Stable Release Policy](#stable-release-policy).
+
+After the release branch has all commits required for the next patch release:
+
+- update `CHANGELOG.md`.
+- create a new annotated git tag (eg `git -a v1.1.0`) in the release branch.
+- Create a GitHub release.
+
+## Major Release Maintenance
+
+Major Release series continue to receive bug fixes (released as a Patch Release) until they reach **End Of Life**.
+Major Release series is maintained in compliance with the **Stable Release Policy** as described in this document.
+Note: not every Major Release is denoted as stable releases.
+
+Only the following major release series have a stable release status:
+>>>>>>> 479485f95 (style: lint go and markdown (#10060)):RELEASE_PROCESS.md
 
 * **0.42 «Stargate»** will be supported until 6 months after **0.43.0** is published. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release.
 * **0.43 «Stargate»** is the latest stable release.
 
+<<<<<<< HEAD:STABLE_RELEASES.md
 The **0.43 «Stargate»** release series is maintained in compliance with the **Stable Release Policy** as described in this document.
 
+=======
+>>>>>>> 479485f95 (style: lint go and markdown (#10060)):RELEASE_PROCESS.md
 ## Stable Release Policy
 
 This policy presently applies *only* to the following release series:

diff --git a/contrib/rosetta/README.md b/contrib/rosetta/README.md
@@ -17,7 +17,15 @@ Contains the required files to set up rosetta cli and make it work against its w
 
 ## node
 
+<<<<<<< HEAD
 Contains the files for a deterministic network, with fixed keys and some actions on there, to test parsing of msgs and historical balances.
+=======
+Contains the files for a deterministic network, with fixed keys and some actions on there, to test parsing of msgs and historical balances.  This image is used to run a simapp node and to run the rosetta server.
+
+## Rosetta-cli
+
+The docker image for ./rosetta-cli/Dockerfile is on [docker hub](https://hub.docker.com/r/tendermintdev/rosetta-cli).  Whenever rosetta-cli releases a new version, rosetta-cli/Dockerfile should be updated to reflect the new version and pushed to docker hub.
+>>>>>>> 479485f95 (style: lint go and markdown (#10060))
 
 ## Notes