Merge PR #4205: Mircea/update contributing md

* Update `CONTRIBUTING.md` branching strategy and release process

* Delete PRIORITIES.md

* Delete RELEASE_PROCESS.md

* Remove RELEASE_TEST_SCRIPT.md

* Update CONTRIBUTING.md

Co-Authored-By: mircea-c <mircea@tendermint.com>

CONTRIBUTING.md

@@ -143,8 +143,7 @@ for tcIndex, tc := range cases {
 
 ## Branching Model and Release
 
-User-facing repos should adhere to the branching model: http://nvie.com/posts/a-successful-git-branching-model/.
-That is, these repos should be well versioned, and any merge to master requires a version bump and tagged release.
+User-facing repos should adhere to the trunk based development branching model: https://trunkbaseddevelopment.com/.
 
 Libraries need not follow the model strictly, but would be wise to.
 
@@ -152,37 +151,34 @@ The SDK utilizes [semantic versioning](https://semver.org/).
 
 ### PR Targeting
 
-Ensure that you base and target your PR on the correct branch:
-  - `release/vxx.yy.zz` for a merge into a release candidate
-  - `master` for a merge of a release
-  - `develop` in the usual case
+Ensure that you base and target your PR on the `master` branch.
 
-All feature additions should be targeted against `develop`. Bug fixes for an outstanding release candidate
+All feature additions should be targeted against `master`. Bug fixes for an outstanding release candidate
 should be targeted against the release candidate branch. Release candidate branches themselves should be the
 only pull requests targeted directly against master.
 
 ### Development Procedure:
-  - the latest state of development is on `develop`
-  - `develop` must never fail `make test` or `make test_cli`
-  - `develop` should not fail `make lint`
-  - no --force onto `develop` (except when reverting a broken commit, which should seldom happen)
+  - the latest state of development is on `master`
+  - `master` must never fail `make test` or `make test_cli`
+  - `master` should not fail `make lint`
+  - no `--force` onto `master` (except when reverting a broken commit, which should seldom happen)
   - create a development branch either on github.com/cosmos/cosmos-sdk, or your fork (using `git remote add origin`)
-  - before submitting a pull request, begin `git rebase` on top of `develop`
+  - before submitting a pull request, begin `git rebase` on top of `master`
 
 ### Pull Merge Procedure:
-  - ensure pull branch is rebased on develop
+  - ensure pull branch is rebased on `master`
   - run `make test` and `make test_cli` to ensure that all tests pass
   - merge pull request
-  - push master may request that pull requests be rebased on top of `unstable`
 
 ### Release Procedure:
-  - start on `develop`
-  - prepare changelog/release issue
-  - bump versions
-  - push to release-vX.X.X to run CI
-  - merge to master
-  - merge master back to develop
-
+  - start on `master`
+  - create the release candidate branch `rcN/v*` (please start with `N=1`) (going forward known as **RC**) and ensure it's protected against pushing from anyone except the release manager/coordinator. **no PRs targeting this branch should be merged unless exceptional circumstances arise**
+  - on the `RC` branch, use `clog` to prepare the `CHANGELOG.md` and kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks).
+  - if errors are found during the simulation testing, commit the fixes to `master` and create a new `RC` branch (making sure to increment the `rcN`)
+  - after simulation has successfully completed, create the release branch (`release/vX.XX.X`) from the `RC` branch
+  - merge the release branch to `master` to incorporate the `CHANGELOG.md` updates
+  - delete the `RC` branches
+ 
 ### Hotfix Procedure:
   - start on `master`
   - checkout a new branch named hotfix-vX.X.X
@@ -191,6 +187,5 @@ only pull requests targeted directly against master.
     - add a note to CHANGELOG.md
   - bump versions
   - push to hotfix-vX.X.X to run the extended integration tests on the CI
-  - merge hotfix-vX.X.X to master
-  - merge hotfix-vX.X.X to develop
+  - merge hotfix-vX.X.X to `master` and cherry pick the commit to any release branches this applies to
   - delete the hotfix-vX.X.X branch

docs/PRIORITIES.md

@@ -1,48 +0,0 @@
-# Post-0.25/GoS Pre-Release
-
-## Staking / Slashing - Stability
-
-- [Prelaunch Issues](https://github.com/cosmos/cosmos-sdk/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Astaking+label%3Aprelaunch-2.0)
-
-## Multisig
-
-- Need to test changes in https://github.com/cosmos/cosmos-sdk/pull/2165
-- Spam prevention - https://github.com/cosmos/cosmos-sdk/issues/2019
-
-## ABCI Changes
-
-- CheckEvidence/DeliverEvidence
-- CheckTx/DeliverTx ordering semantics
-- ABCI Error string update (only on the SDK side)
-- Need to verify correct proposer reward semantics
-
-## Gas
-
-- Write specification and explainer document for Gas in Cosmos
-  * Charge for transaction size
-  * Decide what "one gas" corresponds to (standard hardware benchmarks?)
-  * Consider charging based on maximum depth of IAVL tree iteration
-- Test out gas estimation in CLI and LCD and ensure the UX works
-
-## LCD
-
-- Bianje working with Voyager team (@fedekunze) to complete implementation and documentation.
-
-## Documentation
-
-- gaiad / gaiacli
-- LCD
-- Each module
-- Tags [#1780](https://github.com/cosmos/cosmos-sdk/issues/1780)
-# Lower priority
-
-- Create some diagrams (see `docs/resources/diagrams/todo.md`) 
-
-## Governance v2
-
-- Circuit breaker - https://github.com/cosmos/cosmos-sdk/issues/926
-- Parameter change proposals (roughly the same implementation as circuit breaker)
-
-## Staking / Slashing - Stability
-
-- Consider "tombstone" / "prison" - double-sign and you can never validate again - https://github.com/cosmos/cosmos-sdk/issues/2363

docs/RELEASE_PROCESS.md

@@ -1,13 +0,0 @@
-### `cosmos/cosmos-sdk` Release Process
-
-Unless otherwise stated, all of the following tasks will be undertaken by the release manager/coordinator:
-
-- [ ] 1. Decide on release designation (are we doing a patch, or minor version bump)
-- [ ] 2. Ensure that all commits/PRs which are destined for this release are merged to the `master` branch
-- [ ] 3. Create the release candidate branch `rcN` (please start with `N=1`) (going forward known as **RC**) and ensure it's protected against pushing from anyone except the release manager/coordinator. **no PRs targeting this branch should be merged unless exceptional circumstances arise**
-- [ ] 4. On the `RC` branch, use `clog` to prepare the `CHANGELOG.md`.
-- [ ] 5. Summarize breaking API changes section under “Breaking Changes” section to the `CHANGELOG.md` to bring attention to any breaking API changes that affect RPC consumers.
-- [ ] 6. Kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks) 
-- [ ] 7. If errors are found in either #6 or #7 go back to #2 (*NOTE*: be sure to increment the `rcN`)
-- [ ] 8. After #6 and #7 have successfully completed create the release branch from the `RC` branch (this will trigger the automated relase process which will build binaries, tag the release and push to github)
-- [ ] 9. Merge the release branch to `master` and delete the `RC` branch

docs/RELEASE_TEST_SCRIPT.md

@@ -1,17 +0,0 @@
-This document should contain plain english instructions for testing functionality on `gaiad`. This “Script” is supposed to be run by 2 people who will each spin up a `gaiad` node and run the series of prompts below.
-
-- [Create a network of 2 nodes](./gaia/deploy-testnet.md)
-- [Generate an account](./gaia/gaiacli.md)
-- [Send funds from one account to the other](./gaia/gaiacli.md)
-- [Create a validator](./gaia/validators/validator-setup.md)
-- [Edit a validator](./gaia/alidators/validator-setup.md)
-- [Delegate to validator](./gaia/gaiacli.md)
-- [Unbond from a validator](./gaia/gaiacli.md)
-- [View validators and verify output](./gaia/validators/validator-setup.md)
-- [Query network status](./gaia/join-testnet.md#run-a-full-node)
-- [Create a proposal](./gaia/validators/validator-setup.md)
-- [Query a proposal](./gaia/validators/validator-setup.md)
-- [Vote on a proposal](./gaia/validators/validator-setup.md)
-- [Query status of a proposal](./gaia/validators/validator-setup.md)
-- [Query the votes on a proposal](./gaia/validators/validator-setup.md)
-- [Export state and reload](./gaia/join-testnet.md)